"OpenVPN 2.3.0 and earlier running in UDP mode are subject to chosen ciphertext injection due to a non-constant-time HMAC comparison function. Plaintext recovery may be possible using a padding oracle attack on the CBC mode cipher implementation of the crypto library, optimistically at a rate of about one character per 3 hours. PolarSSL seems vulnerable to such an attack; the vulnerability of OpenSSL has not been verified or tested."
Here's the full summary: https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-f375aa67cc
The vulnerability is not considered serious because a definitive attack vector relies on running OpenVPN with a null cipher. Nevertheless, I would suggest a stable push for 2.3.1 at the earliest opportunity.
I'd be fine with that, but I'll leave it to the security team to decide. Note that we don't support PolarSSL in OpenVPN before 2.3.1.
(In reply to comment #0)
> The vulnerability is not considered serious because a definitive attack
> vector relies on running OpenVPN with a null cipher. Nevertheless, I would
> suggest a stable push for 2.3.1 at the earliest opportunity.
Arches, please test and mark stable:
Target KEYWORDS: "alpha amd64 arm hppa ia64 ~mips ppc ppc64 ~s390 sh sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-freebsd ~amd64-linux ~arm-linux ~x86-linux"
Stable for HPPA.
GLSA request filed.
This issue was resolved and addressed in
GLSA 201311-13 at http://security.gentoo.org/glsa/glsa-201311-13.xml
by GLSA coordinator Sergey Popov (pinkbyte).
The openvpn_decrypt function in crypto.c in OpenVPN 2.3.0 and earlier, when
running in UPD mode, allows remote attackers to obtain sensitive information
via a timing attack involving an HMAC comparison function that does not run
in constant time and a padding oracle attack on the CBC mode cipher.