Bug 960195

Summary: CVE-2013-2061 openvpn: use of non-constant-time memcmp in HMAC comparison in openvpn_decrypt [epel-all]
Product: [Fedora] Fedora EPEL Reporter: Vincent Danen <vdanen>
Component: openvpnAssignee: Steven Pritchard <steve>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: el6CC: bill-bugzilla.redhat.com, gwync, huzaifas, jlieskov, steve
Target Milestone: ---Keywords: Security, SecurityTracking
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: openvpn-2.3.1-1.el5 Doc Type: Release Note
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-22 21:38:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 960192    

Description Vincent Danen 2013-05-06 16:35:11 UTC
This is an automatically created tracking bug!  It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of Fedora EPEL.

For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.

For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs

When creating a Bodhi update request, please use the bodhi submission link
noted in the next comment(s).  This will include the bug IDs of this
tracking bug as well as the relevant top-level CVE bugs.

Please also mention the CVE IDs being fixed in the RPM changelog and the
Bodhi notes field when available.

Please note: this issue affects multiple supported versions of Fedora EPEL.
Only one tracking bug has been filed; please ensure that it is only closed
when all affected versions are fixed.

[bug automatically created by: add-tracking-bugs]

Comment 1 Vincent Danen 2013-05-06 16:35:16 UTC
Please use the following update submission link to create the Bodhi
request for this issue as it contains the top-level parent bug(s) as well
as this tracking bug.  This will ensure that all associated bugs get
updated when new packages are pushed to stable.

Please also ensure that the "Close bugs when update is stable" option
remains checked.

Bodhi update submission link:
https://admin.fedoraproject.org/updates/new/?type_=security&bugs=960192,960195

Comment 2 Fedora Update System 2013-05-06 20:08:02 UTC
openvpn-2.3.1-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/openvpn-2.3.1-1.el5

Comment 3 Fedora Update System 2013-05-07 18:12:26 UTC
Package openvpn-2.3.1-1.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing openvpn-2.3.1-1.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5711/openvpn-2.3.1-1.el5
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2013-05-22 21:38:32 UTC
openvpn-2.3.1-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 5 Bill McGonigle 2013-05-23 13:34:46 UTC
Got this update last night.  It looks like in 2.3.1, existing route scripts break when they just say, e.g.:

  route add -net 172.16.0.0 netmask 255.240.0.0 gw $5

with error:

    /etc/openvpn/hq-routes.up tun0 1500 1545 172.16.1.2 172.16.1.1 init
    WARNING: Failed running command (--up/--down): could not execute external program
    Exiting due to fatal error

The workaround being to fully path 'route' as '/sbin/route'.  Fully pathing isn't a bad idea, but most of the documentation out there looks like the plain 'route' line.

I looked at the openvpn changelog and don't see this being listed as purposeful, except for:

      env_block(): if PATH is not set, add standard PATH setting to env

but that seems to be for win32.c, though maybe a global change made it necessary to fix on win32 and nobody noticed on unix yet.