CVE request: 3 flaws in libobby and libnet6

[Vasiliy Kulikov <segoon () openwall com>]

Hi,

1) the libobby's server checks for users' color collisions before
checking users' passwords.  Any user without password authentication
may check whether a specific color is used by someone.  With knowledge
of person's color preferences he may learn whether a specific person
uses the server.  Also, he may enumerate all default colors and learn
the number of users.

    inc/server_buffer.hpp: 

    bool basic_server_buffer<Document, Selector>::on_auth()
    {
    ...
        // Check colour
        if(!basic_buffer<Document, Selector>::check_colour(colour) )
        {
            error = login::ERROR_COLOUR_IN_USE;
            return false;
        }

        // Check global password
        if(!m_global_password.empty() )
        {
            if(global_password != m_global_password)
            {
                error = login::ERROR_WRONG_GLOBAL_PASSWORD;
                return false;
            }
        }
    ...
    }


2) libobby doesn't check server's SSL certificate and passes the
password in plain text over SSL channel.  All remote clients are
vulnerable to a MITM attack.

    • The attacker (A) learns the client's (C) and the server's (S) IP
        addresses and used ports.
    • A breaks the established TCP connection between C and S.
    • A changes the way C's packets with dst = S are routed, resulting
        in all packets from C to S's IP go to A.  The simplest way is
        ARP cache poisoning.
    • A starts listening on the same IP:port as S did.
    • C notices the connection interruption and tries to reconnect to S.
        (Note: if the client is gobby, this step needs user's interaction.)
    • As all C's packets intended for S are routed to A, so, in reality
        C connects to A, not S.
    • C starts SSL session and, as C doesn't check SSL certificate, he
        think it talks to S.
    • A requests C' password.
    • C passes the password in plain text over SSL channel.


3) libnet6 doesn't check basic_server::id_counter for integer overflow.
This number is used to distinguish among different users.  An attacker
may open UINT_MAX successive connections and get an identifier of the
already established connection, resulting in the connection hijacking.
On i686 uint is a 32 bit counter, so an attacker should be able to open
4.000.000.000 connections to complete the attack.  This is a rather big
number: if an attacker may create 2000 connections per second, it would
took ~24 days of continuous connection attempts.  However, it is a real
threat for servers with a huge uptime.

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments