From ${URL} : TLS certificate check bypass with mbedTLS/PolarSSL ================================================== Project cURL Security Advisory, May 18th 2016 - [Permalink](https://curl.haxx.se/docs/adv_20160518.html) VULNERABILITY ------------- 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. Note: PolarSSL is the old name and releases of the library that nowadays is known and released under the name mbedTLS. We are not aware of any exploit of this flaw. INFO ---- This flaw also affects the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2016-3739 to this issue. AFFECTED VERSIONS ----------------- 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! THE SOLUTION ------------ In version 7.49.0, libcurl properly sets the "hostname" even when it is just an IP address and even when using SSLv3 that doesn't have SNI. A [patch for CVE-2016-3739](https://curl.haxx.se/CVE-2016-3739.patch) is available. RECOMMENDATIONS --------------- We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 7.49.0 B - Apply the patch to your version and rebuild C - Build your libcurl with another TLS backend to work around this flaw. TIME LINE --------- It was first reported to the curl project on April 21st 2016. We contacted distros@...nwall on May 8th. libcurl 7.49.0 was released on May 18 2016, coordinated with the publication of this advisory. CREDITS ------- Reported by Moti Avrahami. Patched by Daniel Stenberg. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
(In reply to Agostino Sarubbo from comment #0) > > @maintainer(s): after the bump, in case we need to stabilize the package, > please let us know if it is ready for the stabilization or not. we can start stabilization. KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
Arches, please stabilize; =net-misc/curl-7.49.0 Stable targets: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
dependency.bad [fatal] 28 net-misc/curl/curl-7.49.0.ebuild: DEPEND: amd64(default/linux/amd64/13.0) [ 'net-libs/mbedtls:0=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']
Stable for PPC64.
Stable for HPPA.
Stable on alpha. (including =net-libs/mbedtls-2.2.1)
arm stable
amd64 stable
x86 stable
it looks like ia64 was dropped when mbedtls was added in 7.46.0-r1, but i can't find any comments/bugs pointing this out or requesting ia64 changes. so nothing beyond 7.45.0 has been tested on ia64 at all so far. along those lines, i haven't seen any requests for keyword testing for mbedtls. i've added keywords for the missing arches to mbedtls now though, and re-added ~ia64 to the newer versions of curl.
(In reply to SpanKY from comment #10) > > along those lines, i haven't seen any requests for keyword testing for > mbedtls. > > i've added keywords for the missing arches to mbedtls now though, and > re-added ~ia64 to the newer versions of curl. I stabilized net-misc/curl-7.49.0 for ppc and net-libs/mbedtls-2.2.1 for arm/ppc/ppc64 Here's what's left: Keywords for net-misc/curl: | | u | | a a a n p r s | n | | l m r h i m m i p i s p | u s | r | p d a m p a 6 i o p c s 3 a x | s l | e | h 6 r 6 p 6 8 p s p 6 c 9 s r 8 | e o | p | a 4 m 4 a 4 k s 2 c 4 v 0 h c 6 | d t | o ----------+---------------------------------+-----+------- 7.45.0 | + + + + + + + ~ o + + o + + + + | o 0 | gentoo 7.47.1 | ~ ~ + + + ~ ~ ~ o ~ + o ~ ~ ~ ~ | o | gentoo [I]7.49.0 | + + + ~ + ~ ~ ~ o + + o ~ ~ ~ + | o | gentoo 7.49.1 | ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ o ~ ~ ~ ~ | o | gentoo Keywords for net-libs/mbedtls: | | u | | a a a n p r s | n | | l m r h i m m i p i s p | u s | r | p d a m p a 6 i o p c s 3 a x | s l | e | h 6 r 6 p 6 8 p s p 6 c 9 s r 8 | e o | p | a 4 m 4 a 4 k s 2 c 4 v 0 h c 6 | d t | o ------+---------------------------------+--------+------- 2.1.3 | ~ ~ ~ o ~ o o ~ o ~ ~ o ~ o ~ ~ | # 0/10 | gentoo 2.2.0 | ~ ~ + o + o o ~ o ~ + o ~ o ~ ~ | o | gentoo 2.2.1 | + + + ~ ~ ~ ~ ~ o + + o ~ ~ ~ + | o | gentoo @hppa can you please stablize =net-libs/mbedtls-2.2.1
net-libs/mbedtls-2.2.1: Stable for HPPA.
sparc stable
ia64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
(In reply to Agostino Sarubbo from comment #14) > ia64 stable. > > Maintainer(s), please cleanup. > Security, please add it to the existing request, or file a new one. okay vulnerable versions cleaned up.
CVE-2016-3739 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-3739): The (1) mbed_connect_step1 function in lib/vtls/mbedtls.c and (2) polarssl_connect_step1 function in lib/vtls/polarssl.c in cURL and libcurl before 7.49.0, when using SSLv3 or making a TLS connection to a URL that uses a numerical IP address, allow remote attackers to spoof servers via an arbitrary valid certificate.
This issue was resolved and addressed in GLSA 201701-47 at https://security.gentoo.org/glsa/201701-47 by GLSA coordinator Thomas Deutschmann (whissi).