Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 31 Oct 2011 09:34:01 -0600
From: Kurt Seifried <>
CC: Vasiliy Kulikov <>, Armin Burgmeier <>,
        Philipp Kern <>
Subject: Re: CVE request: 3 flaws in libobby and libnet6

On 10/30/2011 06:08 AM, Vasiliy Kulikov wrote:
> 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;
>             }
>         }
>     ...
>     }
Please use CVE-2011-4091 for this issue.

> 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.
Please use CVE-2011-4092 for this issue
> 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
> 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.
Please use CVE-2011-4093 for this issue.

Note: these are all available from
> Thanks,


-Kurt Seifried / Red Hat Security Response Team

Powered by blists - more mailing lists

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.