oss-security - CVE request: 3 flaws in libobby and libnet6

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Sun, 30 Oct 2011 16:08:34 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Armin Burgmeier <armin@...39.de>, Philipp Kern <phil@...39.de>
Subject: CVE request: 3 flaws in libobby and libnet6

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

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.