[arch-security] [ASA-201505-20] curl: information leakage

Remi Gacogne rgacogne at archlinux.org
Thu May 28 09:11:32 UTC 2015


Arch Linux Security Advisory ASA-201505-20
==========================================

Severity: Low
Date    : 2015-05-28
CVE-ID  : CVE-2015-3153
Package : curl
Type    : information leakage
Remote  : Yes
Link    : https://wiki.archlinux.org/index.php/CVE

Summary
=======

The package curl before version 7.42.1-1 is vulnerable to information
leakage.

Resolution
==========

Upgrade to 7.42.1-1.

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

The problem has been fixed upstream in version 7.42.1.

Workaround
==========

This issue can be mitigated when using curl >= 7.37.0:
- in libcurl, by setting CURLOPT_HEADEROPT to CURLHEADER_SEPARATE ;
- in command-line, by using --proxy-header.

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

libcurl provides applications a way to set custom HTTP headers to be
sent to the server by using CURLOPT_HTTPHEADER. A similar option is
available for the curl command-line tool with the '--header' option.

When the connection passes through an HTTP proxy the same set of headers
is sent to the proxy as well by default. While this is by design, it has
not necessarily been clear nor understood by application programmers.

Such tunneling over a proxy is done for example when using the HTTPS
protocol - or when explicitly asked for. In this case, the initial
connection to the proxy is made in clear including any custom headers
using the HTTP CONNECT method.

While libcurl provides the CURLOPT_HEADEROPT option to allow
applications to tell libcurl if the headers should be sent to host and
the proxy or use separate lists to the different destinations, it has
still defaulted to sending the same headers to both parties for the sake
of compatibility.

If the application sets a custom HTTP header with sensitive content
(e.g., authentication cookies) without changing the default, the proxy,
and anyone who listens to the traffic between the application and the
proxy, might get access to those values.

Note: this problem doesn't exist when using the CURLOPT_COOKIE option
(or the '--cookie' option) or the HTTP auth options, which are always
sent only to the destination server.

Impact
======

An adversary controlling the HTTP proxy used by client using curl (or
libcurl), or listening to the traffic between the application and the
proxy, can access to potentially sensitive information contained in HTTP
headers.

References
==========

http://curl.haxx.se/docs/adv_20150429.html
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3153

-------------- 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/20150528/1deb26e1/attachment.asc>


More information about the arch-security mailing list