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).
Secure-tunneling please bump and create/update a herd alias.
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.
Arches, please test 2.0.1 and mark stable
Marked Stable on AMD64.
Stable on ppc.
stable on ppc-macos
x86 there...
Waiting on sparc. Ccing jforman which is the last sparc stable-izer, in case he can help.
sparc stable, sorry for the delay.
Ready for GLSA vote, I vote YES
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.
Seems like some very minor issues. Voting NO and closing. Feel free to reopen if you disagree.
*** Bug 106323 has been marked as a duplicate of this bug. ***