From ${URL} : sensitive HTTP server headers also sent to proxies Project cURL Security Advisory, April 29th 2015 - Permalink VULNERABILITY 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. INFO This flaw can also affect the curl command line tool if a similar operation series is made with that. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2015-3153 to this issue. AFFECTED VERSIONS This flaw is relevant for applications that use CURLOPT_HTTPHEADER to set headers with sensitive values and make HTTPS connections to the server via an HTTP proxy. Affected versions: libcurl 7.1 to and include 7.42.0 Not affected versions: libcurl >= 7.42.1 THE SOLUTION In version 7.37.0, libcurl introduced new options allowing applications to control which headers are sent to the proxy and which are sent only to the destination server - CURLOPT_HEADEROPT & CURLOPT_PROXYHEADER. Starting in 7.42.1, the new default for this option will be CURLHEADER_SEPARATE. This has the minor drawback to the rare applications that truly intend the headers to be sent to both parties, that they need to change this option in their application. curl of version >= 7.37 already sends headers that are set with '--header' option only to the destination server iff --proxy-header is also used. A patch for this problem that changes the default is available at (URL will be updated in final advisory): http://curl.haxx.se/CVE-2015-3153.patch @maintainer(s): since the fixed package is already in the tree, please let us know if it is ready for the stabilization or not.
Changing severity 3->4 due to information leakage, A->B due to specific nature requiring proxied setup through untrusted proxy and applications not making use of API to specify header severity.
(In reply to Agostino Sarubbo from comment #0) > @maintainer(s): since the fixed package is already in the tree, please let > us know if it is ready for the stabilization or not. Its good to go KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
stable on arm, ppc and ppc64.
Stable for HPPA.
amd64 stable
CVE-2015-3153 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-3153): The default configuration for cURL and libcurl before 7.42.1 sends custom HTTP headers to both the proxy and destination server, which might allow remote proxy servers to obtain sensitive information by reading the header contents.
ia64 stable
x86 stable
alpha stable
sparc stable
Arches, Thank you for your work. Security Please Vote. First GLSA Vote: No Maintainer(s), please drop the vulnerable version(s).
Ping on Cleanup!
(In reply to Yury German from comment #12) > Ping on Cleanup! done
Maintainer(s), Thank you for you for cleanup.
GLSA Vote: No
