Security: AHC can be tricked into connecting to a different host

[slandelle]

Issue is very similar to CVE-2016-8624 that affected cURL last year.

AHC url parser, org.asynchttpclient.uri.Uri can be tricked with a anchor containing a question mark into connecting to a different host. This issue also affects java.net.URL (as of 8u112) but not java.net.URI:

org.asynchttpclient.uri.Uri.create("http://1.2.3.4:81#@5.6.7.8:82/aaa/b?q").getHost()
// 5.6.7.8

new java.net.URL("http://1.2.3.4:81#@5.6.7.8:82/aaa/b?q").getHost()
// 5.6.7.8

java.net.URI.create("http://1.2.3.4:81#@5.6.7.8:82/aaa/b?q").getHost()
// 1.2.3.4

Credit goes to Nicolas Grégoire from Agarri.

I'm not aware of any exploit at the moment.

Possible usages:

• circumventing white/back lists
• web crawler that would use AHC for fetching pages but would use java.net.URI to compute the index key.

[wsargent]

I think this falls into the category of SSRF checks. There's some research here find-sec-bugs/find-sec-bugs#307 and I've got a (not working) SSRF filter in progress in Play WS playframework/play-ws#118

[slandelle]

@wsargent Thanks for the info. I guess one could implement such filter directly in AHC too.

[ngregoire]

I tested v2.0.35, which looks OK (it now behaves like Java.net.URI).

Regarding exploitability of versions < 2.0.35: it appears that controlling the "path" or "query" parts of the request isn't possible. So, the worst impacts I can think of are:

• in a black/white lists bypass scenario: access to (only) the root page of a forbidden resource => limited information leak (for example, it can't be used to steal private information from AWS metadata servers)
• in an index key collision scenario: malicious update of cache entries => publishing incorrect or NSFW content, attacking users (water-hole or phishing attacks), ...

The second scenario looks worse.

[ngregoire]

CVE-2017-14063 was assigned.