"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. Agreed. Arches, please test and mark stable: =net-misc/openvpn-2.3.1 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"
amd64 stable
x86 stable
alpha stable
arm stable
ia64 stable
ppc64 stable
ppc stable
sparc stable
Stable for HPPA.
s390 stable
sh stable
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).
CVE-2013-2061 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2061): 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.
