CVE-2014-0139

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 easier fool users that it is a legitimate site for whatever purpose, when it actually is not.

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 one previously reported by Richard Moore, found in multiple browsers.

cURL and libcurl 7.1 before 7.36.0, when using the OpenSSL, axtls, qsossl or gskit libraries for TLS, recognize a wildcard IP address in the subject's Common Name (CN) field of an X.509 certificate, which might allow man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority.

cURL and libcurl 7.1 before 7.36.0, when using the OpenSSL, axtls, qsossl or gskit libraries for TLS, recognize a wildcard IP address in the subject's Common Name (CN) field of an X.509 certificate, which might allow man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority.

Updated curl packages fix security vulnerabilities:

Paras Sethia discovered that libcurl would sometimes mix up multiple HTTP and HTTPS connections with NTLM authentication to the same server, sending requests for one user over the connection authenticated as a different user (CVE-2014-0015).

libcurl can in some circumstances re-use the wrong connection when asked to do transfers using other protocols than HTTP and FTP, causing a transfer that was initiated by an application to wrongfully re-use an existing connection to the same server that was authenticated using different credentials (CVE-2014-0138).

libcurl incorrectly validates wildcard SSL certificates containing literal IP addresses, so under certain conditions, it would allow and use a wildcard match specified in the CN field, allowing a malicious server to participate in a MITM attack or just fool users into believing that it is a legitimate site (CVE-2014-0139).

Updated lftp packages fix security vulnerability:

lftp incorrectly validates wildcard SSL certificates containing literal IP addresses, so under certain conditions, it would allow and use a wildcard match specified in the CN field, allowing a malicious server to participate in a MITM attack or just fool users into believing that it is a legitimate site (CVE-2014-0139).

lftp was affected by this issue as it uses code from cURL for checking SSL certificates. The curl package was fixed in MGASA-2014-0153.

These are all security issues fixed in the curl-7.51.0-1.1 package on the GA media of openSUSE Tumbleweed.

These are all security issues fixed in the lftp-4.7.4-1.1 package on the GA media of openSUSE Tumbleweed.

This curl update fixes the following security issues:

* bnc#868627: wrong re-use of connections (CVE-2014-0138).
* bnc#868629: IP address wildcard certificate validation
  (CVE-2014-0139).
* bnc#870444: --insecure option inappropriately enforcing security
  safeguard.

Security Issue references:

* CVE-2014-0138
  <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0138>
* CVE-2014-0139
  <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0139>