[arch-security] [ASA-201504-28] curl: multiple issues

[Remi Gacogne]

Arch Linux Security Advisory ASA-201504-28
==========================================

Severity: Medium
Date    : 2015-04-24
CVE-ID  : CVE-2015-3143 CVE-2015-3144 CVE-2015-3145 CVE-2015-3148
Package : curl
Type    : multiple issues
Remote  : Yes
Link    : https://wiki.archlinux.org/index.php/CVE

Summary
=======

The package curl before version 7.42.0-1 is vulnerable to multiple
issues, including but not limited to denial of service and
authentication bypass for NTLM/Negotiate HTTP authentication.

Resolution
==========

Upgrade to 7.42.0-1.

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

The problem has been fixed upstream in version 7.42.0.

Workaround
==========

None.

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

- CVE-2015-3143 (re-using authenticated connection when unauthenticated):

libcurl keeps a pool of its last few connections around after use to
fascilitate easy, conventient and completely transparent connection
re-use for applications. When doing HTTP requests NTLM authenticated,
the entire connnection becomes authenticated and not just the specific
HTTP request which is otherwise how HTTP works. This makes NTLM special
and a subject for special treatment in the code. With NTLM, once the
connection is authenticated, no further authentication is necessary
until the connection gets closed. libcurl's connection re-use logic will
select an existing connection for re-use when asked to do a request, and
when asked to use NTLM libcurl have to pick a connection with matching
credentials only. If a connection was first setup and used for an NTLM
HTTP request with a specific set of credentials, that same connection
could later wrongly get re-used in a subsequent HTTP request that was
made to the same host - but without having any credentials set! Since an
NTLM connection was already authenticated due to how NTLM works, the
subsequent request could then get sent over the wrong connection
appearing as the initial user. This problem is very similar to the
previous problem known as CVE-2014-0015. The main difference this time
is that the subsequent request that wrongly re-use a connection doesn't
ask for NTLM authentication.

- CVE-2015-3144 (host name out of boundary memory access):

There is a private function in libcurl called fix_hostname() that
removes a trailing dot from the host name if there is one. The function
is called after the host name has been extracted from the URL libcurl
has been told to act on. If a URL is given with a zero-length host name,
like in "http://:80" or just ":80", fix_hostname() will index the host
name pointer with a -1 offset (as it blindly assumes a non-zero length)
and both read and assign that address. At best, this gets unnoticed but
can also lead to a crash or worse. We have not researched further what
kind of malicious actions that potentially this could be used for.

- CVE-2015-3145 (cookie parser out of boundary memory access):

libcurl supports HTTP "cookies" as documented in RFC 6265. Together with
each individual cookie there are several different properties, but for
this vulnerability we focus on the associated "path" element. It tells
information about for which path on a given host the cookies is valid.
The internal libcurl function called sanitize_cookie_path() that cleans
up the path element as given to it from a remote site or when read from
a file, did not properly validate the input. If given a path that
consisted of a single double-quote, libcurl would index a newly
allocated memory area with index -1 and assign a zero to it, thus
destroying heap memory it wasn't supposed to. At best, this gets
unnoticed but can also lead to a crash or worse. We have not researched
further what kind of malicious actions that potentially this could be
used for. Applications have to explicitly enable cookie parsing in
libcurl for this problem to trigger, and if not enabled libcurl will not
hit this problem.

- CVE-2015-3148 (negotiate not treated as connection-oriented):

libcurl keeps a pool of its last few connections around after use to
fascilitate easy, conventient and completely transparent connection
re-use for applications. When doing HTTP requests Negotiate
authenticated, the entire connnection may become authenticated and not
just the specific HTTP request which is otherwise how HTTP works, as
Negotiate can basically use NTLM under the hood. curl was not adhering
to this fact but would assume that such requests would also be
authenticated per request. The net effect is that libcurl may end up
re-using an authenticated Negotiate connection and sending subsequent
requests on it using new credentials, while the connection remains
authenticated with a previous initial credentials setup.

Impact
======

An attacker controlling the URL supplied to libcurl can cause a denial
of service or other unspecified impact.
A remote attacker controlling a malicious server, or an active attacker
in position of man-in-the-middle, may be able to cause a denial of
service or other unspecified impact if cookie parsing has been enabled.
An attacker may be able to bypass authentication by tricking libcurl
into reusing an already authenticated HTTP connection using NTLM or
Negotiate authentication.

References
==========

https://access.redhat.com/security/cve/CVE-2015-3143
https://access.redhat.com/security/cve/CVE-2015-3144
https://access.redhat.com/security/cve/CVE-2015-3145
https://access.redhat.com/security/cve/CVE-2015-3148
http://curl.haxx.se/docs/adv_20150422A.html
http://curl.haxx.se/docs/adv_20150422B.html
http://curl.haxx.se/docs/adv_20150422C.html
http://curl.haxx.se/docs/adv_20150422D.html

-------------- 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/20150424/e21fed8b/attachment.asc>