Bug 1362190 (CVE-2016-5420)

Summary:	CVE-2016-5420 curl: Re-using connection with wrong client cert
Product:	[Other] Security Response	Reporter:	Adam Mariš <amaris>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	alonbl, apmukher, bmcclain, bodavis, cfergeau, csutherl, dbhole, dblechte, eedri, hhorak, jclere, jorton, kanderso, kdreyer, kdudka, lgao, lsurette, luhliari, mbabacek, mgoldboi, michal.skrivanek, myarboro, omajid, rwagner, sardella, security-response-team, sisharma, slawomir, srevivo, twalsh, weli, ykaul
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	curl 7.50.1	Doc Type:	Bug Fix
Doc Text:	It was found that the libcurl library did not check the client certificate when choosing the TLS connection to reuse. An attacker could potentially use this flaw to hijack the authentication of the connection by leveraging a previously created connection with a different client certificate.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-06-08 02:57:07 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:	1363642, 1363643, 1363644, 1364910, 1367875
Bug Blocks:	1362200, 1395463

Description Adam Mariš 2016-08-01 13:32:51 UTC

It was reported that 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.

External Reference:

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

Comment 1 Adam Mariš 2016-08-03 09:24:56 UTC

Created curl tracking bugs for this issue:

Affects: fedora-all [bug 1363642]

Comment 2 Adam Mariš 2016-08-03 09:25:05 UTC

Created mingw-curl tracking bugs for this issue:

Affects: fedora-all [bug 1363643]
Affects: epel-7 [bug 1363644]

Comment 3 Fedora Update System 2016-08-05 20:52:29 UTC

curl-7.47.1-6.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 5 Fedora Update System 2016-08-16 22:21:05 UTC

curl-7.43.0-8.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 10 errata-xmlrpc 2016-11-03 17:45:10 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:2575 https://rhn.redhat.com/errata/RHSA-2016-2575.html

Comment 12 errata-xmlrpc 2016-12-15 22:11:57 UTC

This issue has been addressed in the following products:



Via RHSA-2016:2957 https://rhn.redhat.com/errata/RHSA-2016-2957.html

Comment 13 errata-xmlrpc 2018-11-13 08:32:01 UTC

This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 6
  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS

Via RHSA-2018:3558 https://access.redhat.com/errata/RHSA-2018:3558