oss-sec mailing list archives
CVE request: 3 flaws in libobby and libnet6
From: Vasiliy Kulikov <segoon () openwall com>
Date: Sun, 30 Oct 2011 16:08:34 +0400
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
Current thread:
- CVE request: 3 flaws in libobby and libnet6 Vasiliy Kulikov (Oct 30)
- Re: CVE request: 3 flaws in libobby and libnet6 Armin Burgmeier (Oct 30)
- Re: CVE request: 3 flaws in libobby and libnet6 Vasiliy Kulikov (Oct 30)
- Re: CVE request: 3 flaws in libobby and libnet6 Kurt Seifried (Oct 31)
- Re: CVE request: 3 flaws in libobby and libnet6 Armin Burgmeier (Oct 30)