Bug 102871 - net-misc/openvpn: Multiple DoS issues
|
Bug#:
102871
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: minor
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: carlo@gentoo.org
|
|
Component: Vulnerabilities
|
|
|
URL:
|
|
Summary: net-misc/openvpn: Multiple DoS issues
|
|
Keywords:
|
|
Status Whiteboard: C3 [noglsa] jaervosz
|
|
Opened: 2005-08-17 10: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).
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
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. ***