cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: [SECURITY VULNERABILITY] curl: Re-using connections with wrong client cert

From: Kamil Dudka <kdudka_at_redhat.com>
Date: Mon, 05 Sep 2016 14:14:32 +0200

On Wednesday, August 03, 2016 09:05:26 Daniel Stenberg wrote:
> Re-using connections with wrong client cert
> ===========================================
>
> Project cURL Security Advisory, August 3rd 2016 -
> [Permalink](https://curl.haxx.se/docs/adv_20160803B.html)

After torture-testing the patch for CVE-2016-5420, it was discovered that
libcurl built on top of NSS (Network Security Services) still incorrectly
re-uses client certificates if a certificate from file is used for one TLS
connection but no certificate is set for a subsequent TLS connection.

This problem was caused by an implementation detail of the NSS backend
in libcurl, which is orthogonal to the cause of CVE-2016-5420. Users of
libcurl/NSS that load client certificates from files are encouraged to
also apply the attached follow-up patch.

The original patch for CVE-2016-5420 has been amended to also contain the
attached patch:

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

> VULNERABILITY
> -------------
>
> libcurl did not consider client certificates when reusing TLS connections.
>
> libcurl supports reuse of established connections for subsequent requests.
> It does this by keeping a few previous connections "alive" in a connection
> pool so that a subsequent request that can use one of them instead of
> creating a new connection will do so.
>
> When using a client certificate for a connection that was then put into the
> connection pool, that connection could then wrongly get reused in a
> subsequent request to that same server that either didn't use a client
> certificate at all or that asked to use a different client certificate thus
> trying to tell the user that it is a different entity.
>
> This mistakenly using the wrong connection could of course lead to
> applications sending requests to the wrong realms of the server using
> authentication that it wasn't supposed to have for those operations.
>
> 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-5420 to this issue.
>
> AFFECTED VERSIONS
> -----------------
>
> This flaw is relevant for all versions of curl and libcurl that support
> SSL/TLS and client certificates.
>
> - Affected versions: libcurl 7.1 to and including 7.50.0
> - Not affected versions: libcurl >= 7.50.1
>
> libcurl is used by many applications, but not always advertised as such!
>
> THE SOLUTION
> ------------
>
> In version 7.50.1, curl will check that re-used connections have the correct
> client certificate (file name) before used.
>
> A [patch for CVE-2016-5420](https://curl.haxx.se/CVE-2016-5420.patch) is
> available. This patch relies on the
> [CVE-2016-5419](https://curl.haxx.se/docs/adv_20160803A.html) patch already
> having been applied.
>
> RECOMMENDATIONS
> ---------------
>
> We suggest you take one of the following actions immediately, in order of
> preference:
>
> A - Upgrade curl and libcurl to version 7.50.1
>
> B - Apply the patch to your version and rebuild
>
> C - Do not use client certificates
>
> TIME LINE
> ---------
>
> This was figured out by curl security team members during our work with the
> 20160803A flaw during June 2016. We contacted distros_at_openwall on July 31.
>
> libcurl 7.50.1 was released on August 3 2016, coordinated with the
> publication of this advisory.
>
> CREDITS
> -------
>
> Found by the curl security team. Patch by Daniel Stenberg.
>
> Thanks a lot!
Received on 2016-09-05