Bug 1335430 (CVE-2016-3739)

Summary: CVE-2016-3739 curl: TLS certificate name check bypass with mbedTLS and PolarSSL
Product: [Other] Security Response Reporter: Martin Prpič <mprpic>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: alonbl, bmcclain, cfergeau, csutherl, dblechte, dknox, eedri, gklein, jclere, jdoyle, kdudka, lgao, lsurette, mbabacek, mgoldboi, michal.skrivanek, mprpic, myarboro, rbalakri, sardella, security-response-team, sherold, srevivo, twalsh, weli, ykaul, ylavi
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: curl 7.49.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-12 08:52:28 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: 1335432    

Description Martin Prpič 2016-05-12 08:39:38 UTC
The following flaw was found in libcurl:

libcurl did not check the server certificate of TLS connections done to a host specified as an IP address, or when explicitly asked to use SSLv3.

This flaw only exists when libcurl is built to use mbedTLS or PolarSSL as TLS backend.

The documentation for mbedTLS and PolarSSL (wrongly) says that the API function *ssl_set_hostname() is used only for setting the name for the TLS extension SNI. The set string is however even more importantly used by the libraries to verify the server certificate, and if no "hostname" is set it will just skip the check and successfully continue with the handshake.

libcurl would wrongly avoid using the function when the specified host name was given as an IP address or when SSLv3 is used, as SNI isn't supposed to be used then. This then leads to that all uses of TLS oriented protocols (HTTPS, FTPS, IMAPS, POPS3, SMTPS, etc) will allow connections to servers with unverified server certificates as long as they're specified as IP addresses or using SSLv3.

By tricking a libcurl-using client to use a URL with a host specified as IP address only, an application could be made to connect to an impostor server or Man In The Middle host without noticing.

This flaw also affects the curl command line tool.

Upstream patch:

https://curl.haxx.se/CVE-2016-3739.patch

External References:

https://curl.haxx.se/docs/adv_20160518.html

Comment 1 Tomas Hoger 2016-05-12 08:52:28 UTC
The curl package distributed in Red Hat products use either OpenSSL or NSS libraries to implement TLS/SSL support.  As this is specific to builds using mbedTLS or PolarSSL, they are not affected by this issue.

Comment 2 Tomas Hoger 2016-05-12 08:54:10 UTC
Additional information on affected versions form the upstream advisory draft:

This flaw is relevant for all versions of curl and libcurl that support
PolarSSL or mbedTLS.

- Affected versions: libcurl 7.21.0 to and including 7.48.0
- Not affected versions: libcurl < 7.21.0 and libcurl >= 7.49.0

libcurl is used by many applications, but not always advertised as such!

Comment 3 Tomas Hoger 2016-05-12 09:00:12 UTC
Acknowledgement:

Name: Daniel Stenberg (curl upstream)
Upstream: Moti Avrahami