[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 31 Oct 2011 09:34:01 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Vasiliy Kulikov <segoon@...nwall.com>, Armin Burgmeier <armin@...39.de>,
Philipp Kern <phil@...39.de>
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
> 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
> 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.
