102871 2005-08-17 10:21 0000 net-misc/openvpn: Multiple DoS issues 2005-09-18 02:28:08 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All Linux RESOLVED FIXED C3 [noglsa] jaervosz P2 minor --- 103320 1 carlo@gentoo.org security@gentoo.org kaiowas@gentoo.org luckyduck@gentoo.org mr-russ@pws.com.au warpzero@gentoo.org carlo@gentoo.org 2005-08-17 10:21:21 0000 2005.08.16 -- Version 2.0.1 * Security Fix -- DoS attack against server when run with "verb 0" and without "tls-auth". If a client connection to the server fails certificate verification, the OpenSSL error queue is not properly flushed, which can result in another unrelated client instance on the server seeing the error and responding to it, resulting in disconnection of the unrelated client (CAN-2005-2531). * Security Fix -- DoS attack against server by authenticated client. This bug presents a potential DoS attack vector against the server which can only be initiated by a connected and authenticated client. If the client sends a packet which fails to decrypt on the server, the OpenSSL error queue is not properly flushed, which can result in another unrelated client instance on the server seeing the error and responding to it, resulting in disconnection of the unrelated client (CAN-2005-2532). * Security Fix -- DoS attack against server by authenticated client. A malicious client in "dev tap" ethernet bridging mode could theoretically flood the server with packets appearing to come from hundreds of thousands of different MAC addresses, causing the OpenVPN process to deplete system virtual memory as it expands its internal routing table. A --max-routes-per-client directive has been added (default=256) to limit the maximum number of routes in OpenVPN's internal routing table which can be associated with a given client (CAN-2005-2533). * Security Fix -- DoS attack against server by authenticated client. If two or more client machines try to connect to the server at the same time via TCP, using the same client certificate, and when --duplicate-cn is not enabled on the server, a race condition can crash the server with "Assertion failed at mtcp.c:411" (CAN-2005-2534). * Fixed server bug where under certain circumstances, the client instance object deletion function would try to delete iroutes which had never been added in the first place, triggering "Assertion failed at mroute.c:349". * Added --auth-retry option to prevent auth errors from being fatal on the client side, and to permit username/password requeries in case of error. Also controllable via new "auth-retry" management interface command. See man page for more info. * Added easy-rsa 2.0 scripts to the tarball in easy-rsa/2.0 * Fixed bug in openvpn.spec where rpmbuild --define 'without_pam 1' would fail to build. * Implement "make check" to perform loopback tests (Matthias Andree). jaervosz@gentoo.org 2005-08-17 21:57:15 0000 Secure-tunneling please bump and create/update a herd alias. kaiowas@gentoo.org 2005-08-20 23:40:56 0000 according to devaway, cia and genbot luckyduck might still have connection problems. a new shiny openvpn ebuild is available. tested and found OK on x86, unmask when you see fit. koon@gentoo.org 2005-08-21 07:26:03 0000 Arches, please test 2.0.1 and mark stable metalgod@gentoo.org 2005-08-21 09:15:40 0000 Marked Stable on AMD64. hansmi@gentoo.org 2005-08-21 10:17:01 0000 Stable on ppc. grobian@gentoo.org 2005-08-21 11:33:55 0000 stable on ppc-macos tester@gentoo.org 2005-08-24 15:59:25 0000 x86 there... koon@gentoo.org 2005-08-25 11:43:59 0000 Waiting on sparc. Ccing jforman which is the last sparc stable-izer, in case he can help. gustavoz@gentoo.org 2005-08-30 05:58:22 0000 sparc stable, sorry for the delay. koon@gentoo.org 2005-08-30 08:35:50 0000 Ready for GLSA vote, I vote YES taviso@gentoo.org 2005-08-30 09:30:39 0000 vote NO, sound like very minor issues for non-authenticated clients presumably the sequence of events to stop people connecting would have to be: -> attacker sends data that cannot be decrypted -> legitimate user connects, but connection fails -> attacker again -> legitimate user -> attacker The attacker cant connect again before the legitimate user, or he would flush his own message queue? so would have to wait until he knows the legitimate user has failed, then send the bad data again, I dont think this is a feasible attack to prevent more than one or two connections. The attacks from authenticated users are less minor, but not glsa worthy imho. jaervosz@gentoo.org 2005-08-30 12:24:01 0000 Seems like some very minor issues. Voting NO and closing. Feel free to reopen if you disagree. koon@gentoo.org 2005-09-18 02:28:08 0000 *** Bug 106323 has been marked as a duplicate of this bug. ***