[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1649028.3J7HsOb28o@kdudka-nb>
Date: Mon, 05 Sep 2016 14:14:32 +0200
From: Kamil Dudka <kdudka@...hat.com>
To: curl-users@...l.haxx.se, curl-announce@...l.haxx.se,
libcurl hacking <curl-library@...l.haxx.se>,
oss-security@...ts.openwall.com
Cc: Daniel Stenberg <daniel@...x.se>
Subject: Re: [SECURITY VULNERABILITY] curl: Re-using connections with wrong client cert
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@...nwall 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!
View attachment "0001-nss-refuse-previously-loaded-certificate-from-file.patch" of type "text/x-patch" (1525 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
