Bug 960192 - (CVE-2013-2061) CVE-2013-2061 openvpn: use of non-constant-time memcmp in HMAC comparison in openvpn_decrypt
CVE-2013-2061 openvpn: use of non-constant-time memcmp in HMAC comparison in ...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20130322,reported=2...
: Security
Depends On: 960195 960196
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-06 12:25 EDT by Vincent Danen
Modified: 2013-06-04 13:46 EDT (History)
5 users (show)

See Also:
Fixed In Version: openvpn 2.3.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-04 13:46:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2013-05-06 12:25:51 EDT
According to the upstream security report [1] the following flaw was found in OpenVPN 2.3.0 and earlier:


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.

OpenVPN servers are typically configured to silently drop packets with the wrong HMAC. For this reason measuring the processing time of the packets is not trivial without a MITM position. In practice, the attack likely needs some target-specific information to be effective.

The severity of this vulnerability can be considered low. Only if OpenVPN is configured to use a null-cipher, arbitrary plain-text can be injected which can completely open up this attack vector.


A fix has been committed to git [2]; this is corrected in OpenVPN 2.3.1 and later.

[1] https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-f375aa67cc
[2] https://github.com/OpenVPN/openvpn/commit/11d21349a4e7e38a025849479b36ace7c2eec2ee
Comment 1 Vincent Danen 2013-05-06 12:30:14 EDT
Note that OpenVPN is not built with PolarSSL support, so while it's currently unknown whether or not this affects OpenVPN built with OpenSSL, it's probably prudent to apply the patch, despite this being a low-impact flaw.
Comment 2 Gwyn Ciesla 2013-05-06 12:32:30 EDT
Pushing 2.3.1 to f18 and f17 as we speak.
Comment 3 Vincent Danen 2013-05-06 12:34:50 EDT
Nice, thank you Jon.  I will still file a tracking bug that you can reference as one is required for EPEL anyways.
Comment 4 Vincent Danen 2013-05-06 12:35:28 EDT
Created openvpn tracking bugs for this issue

Affects: epel-all [bug 960195]
Affects: fedora-all [bug 960196]
Comment 5 David Sommerseth 2013-05-06 13:56:03 EDT
For more information about this issue, please read this announcement:

https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-f375aa67cc

This is really a low security issue, and it seems most likely to be vulnerable only if --cipher none is used in the configuration.
Comment 6 Vincent Danen 2013-05-06 17:10:20 EDT
Right, that's why it's rated low impact here as well.  It's also unknown whether or not this affects openssl (which we use) or just the use of polarssl (which we don't use).  But, regardless, it's still a flaw and the patch is pretty straightforward, so there's no real reason _not_ to fix it.
Comment 7 Jan Lieskovsky 2013-05-07 03:39:57 EDT
The CVE identifier of CVE-2013-2061 has been assigned to this issue:
  http://www.openwall.com/lists/oss-security/2013/05/06/6

Note You need to log in before you can comment on or make changes to this bug.