Bug 1079149 (CVE-2014-0139)

Summary:	CVE-2014-0139 curl: IP address wildcard certificate validation issue in libcurl
Product:	[Other] Security Response	Reporter:	Murray McAllister <mmcallis>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	carnil, jkurik, jrusnack, kdudka, pfrields, security-response-team, yselkowi
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	curl 7.36.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-07 11:26:39 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:	1080880, 1080891
Bug Blocks:	1053909

Description Murray McAllister 2014-03-21 05:02:15 UTC

Daniel Stenberg reported the following vulnerability in cURL:

libcurl incorrectly validates wildcard SSL certificates containing literal
IP addresses.

RFC 2818 covers the requirements for matching Common Names (CNs) and
subjectAltNames in order to establish valid SSL connections. It first
discusses CNs that are for hostnames, and the rules for wildcards in this
case. The next paragraph in the RFC then discusses CNs that are IP
addresses:

'In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present in the
certificate and must exactly match the IP in the URI.'

The intention of the RFC is clear in that you should not be able to use
wildcards with IP addresses (in order to avoid the ability to perform
man-in-the-middle attacks). Unfortunately libcurl fails to adhere to this
rule under certain conditions, and subsequently it would allow and use a
wildcard match specified in the CN field.

Exploiting this flaw, a malicious server could participate in a MITM attack
or just easier fool users that it is a legitimate site for whatever purpose,
when it actually isn't.

A good CA should refuse to issue a certificate with the CN as indicated,
however there only need be one CA to issue one in error for this issue to
result in the user getting no warning at all and being vulnerable to MITM.

This flaw is only present in libcurl when built to use one out of a few
specific TLS libraries: OpenSSL, axtls, qsossl or gskit.

This problem is similar to the one previously reported by Richard Moore,
found in multiple browsers [1].

[1] http://www.westpoint.ltd.uk/advisories/wp-10-0001.txt (this is CVE-2010-3170)

Versions 7.1 to and including 7.35.0 are affected. The flaw is fixed in version 7.36.0

Acknowledgements:

Red Hat would like to thank the cURL project for reporting this issue. Upstream acknowledges Richard Moore from Westpoint Ltd. as the original reporter.

Comment 4 Tomas Hoger 2014-03-26 09:42:46 UTC

Fixed now upstream in curl version 7.36.0.

External References:

http://curl.haxx.se/docs/adv_20140326B.html

Comment 5 Tomas Hoger 2014-03-26 09:44:14 UTC

Created mingw32-curl tracking bugs for this issue:

Affects: epel-5 [bug 1080891]

Comment 6 Tomas Hoger 2014-03-26 09:44:18 UTC

Created mingw-curl tracking bugs for this issue:

Affects: fedora-all [bug 1080880]

Comment 7 Tomas Hoger 2014-04-25 12:43:12 UTC

Upstream commit:

https://github.com/bagder/curl/commit/5019c78

Comment 8 Vincent Danen 2014-05-27 15:18:01 UTC

Statement:

This issue did not affect the versions of curl as shipped with Red Hat Enterprise Linux 6 and 7 because it uses the NSS backend, not OpenSSL.  It does affect Red Hat Enterprise Linux 5 which uses the OpenSSL backend.

Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Low security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.

Comment 10 Yaakov Selkowitz 2015-06-10 04:18:18 UTC

It seems this also affects lftp and is fixed in 4.6.2:

https://github.com/lavv17/lftp/commit/6357bed2583171b7515af6bb6585cf56d2117e3f