mailing list archives
Re: CVE request: 3 flaws in libobby and libnet6
From: Kurt Seifried <kseifried () redhat com>
Date: Mon, 31 Oct 2011 09:34:01 -0600
On 10/30/2011 06:08 AM, Vasiliy Kulikov wrote:
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.
bool basic_server_buffer<Document, Selector>::on_auth()
// Check colour
if(!basic_buffer<Document, Selector>::check_colour(colour) )
error = login::ERROR_COLOUR_IN_USE;
// Check global password
if(global_password != m_global_password)
error = login::ERROR_WRONG_GLOBAL_PASSWORD;
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
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.
Please use CVE-2011-4093 for this issue.
Note: these are all available from http://gobby.0x539.de/trac/wiki/Download
-Kurt Seifried / Red Hat Security Response Team