[arch-security] [ASA-201608-9] curl: multiple issues

[Remi Gacogne]

Arch Linux Security Advisory ASA-201608-9
=========================================

Severity: Medium
Date    : 2016-08-08
CVE-ID  : CVE-2016-5419 CVE-2016-5420 CVE-2016-5421
Package : curl
Type    : multiple issues
Remote  : Yes
Link    : https://wiki.archlinux.org/index.php/CVE

Summary
=======

The package curl before version 7.50.1-1 is vulnerable to multiple issues.

Resolution
==========

Upgrade to 7.50.1-1.

# pacman -Syu "curl>=7.50.1-1"

The problems have been fixed upstream in version 7.50.1.

Workaround
==========

None.

Description
===========

- CVE-2016-5419 (authentication bypass)

libcurl would attempt to resume a TLS session even if the client
certificate had changed. That is unacceptable since a server by
specification is allowed to skip the client certificate check on resume,
and may instead use the old identity which was established by the
previous certificate (or no certificate).

- CVE-2016-5420 (authentication bypass)

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.

- CVE-2016-5421 (arbitrary code execution)

libcurl works with easy handles using the type 'CURL *' that are objects
the application creates using curl_easy_init(). They are the handles
that are all each associated with a single transfer at a time. libcurl
also has an internal struct that represents and holds most state that is
related to a single connection. An easy handle can hold references to
one or many such connection structs depending on the requested operations.
When using libcurl's multi interface, an application performs transfers
by adding one or more easy handles to the multi handle and then it can
drive all those transfers in parallel.
Due to a flaw, libcurl could leave a pointer to a freed connection
struct dangling in an easy handle that was previously added to a multi
handle when curl_multi_cleanup() is called with an easy handle still
added to it. This does not seem to cause any notable harm if the handle
is then closed properly.
However, if the easy handle would instead get used again with the easy
interface and curl_easy_perform() to do another transfer, it would
blindly use the connection struct pointer now pointing to freed memory.
An application could be made to allocate its own fake version of the
connect struct, fill in some data and then have the curl_easy_perform()
call do something that clearly was not intended by the original code.

Impact
======

A remote attacker might be able to bypass TLS client certificate
authentication by tricking an application using libcurl into reusing an
existing TLS session.
A local attacker might be able to execute arbitrary code on the affected
host by tricking an application using libcurl into reusing an easy handle.

References
==========

https://curl.haxx.se/docs/adv_20160803A.html
https://curl.haxx.se/docs/adv_20160803B.html
https://curl.haxx.se/docs/adv_20160803C.html
https://access.redhat.com/security/cve/CVE-2016-5419
https://access.redhat.com/security/cve/CVE-2016-5420
https://access.redhat.com/security/cve/CVE-2016-5421

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-security/attachments/20160808/31f4851b/attachment.asc>