Bugzilla Bug 102871

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. ***