Vulnerabilities described below are likely these ones reported in bpo-30500, but it would be nice to double check if *all* reported vulnerabilities have been fixed!
http://python-security.readthedocs.io/vuln/bpo-30500_urllib_connects_to_a_wrong_host.html

--

At July 27, 2017, Orange Tsai (Security Consultant, DEVCORE) reported vulnerabilities in Python, in the code parsing URLs.

Conference: https://www.blackhat.com/us-17/briefings/schedule/#a-new-era-of-ssrf---exploiting-url-parser-in-trending-programming-languages-6292
Slides: https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf

His following blog post only contains the vulnerabilities in Python:
http://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html

Note: His twitter account, https://twitter.com/orange_8361


== Issue 1 ==

* CR-LF Injection on HTTP protocol
* Smuggling SMTP protocol over HTTP protocol


http://127.0.0.1:25/%0D%0AHELO orange.tw%0D%0AMAIL FROM
>> GET /
<< 421 4.7.0 ubuntu Rejecting open proxy localhost [127.0.0.1]
>> HELO orange.tw
Connection closed

=> "SMTP Hates HTTP Protocol It Seems Unexploitable"

"Gopher Is Good What If There Is No Gopher Support?"

"HTTPS What Won't Be Encrypted in a SSL Handshake?"


== Issue 2 ==

* HTTPS: What Won't Be Encrypted in a SSL Handshake?
* Exploit the Unexploitable - Smuggling SMTP over TLS SNI

https://127.0.0.1□%0D%0AHELO□orange.tw%0D%0AMAIL□FROM...:25/
(...)
>< HELO orange.tw
<< 250 ubuntu Hello localhost [127.0.0.1], please meet you
>> MAIL FROM: <admin@orange.tw>
<< 250 2.1.0 <admin@orange.tw>... Sender ok


== Big Picture ==

Python vulnerable to:

* Python httplib:

  * CR-LF Injection: Path, Host and SNI

* Python urllib: 

  * CR-LF Injection: Host and SNI
  * Host Injection

* Python urllib2

  * CR-LF Injection: Host and SNI

The square □ in the strings represents a space.

Issue 1 (CRLF in HTTP request path): it looks like the %0D%0A would have to be decoded by an earlier step in the chain to "http://127.0.0.1:25/\r\nHELO . . .". This becomes like the header injection I mentioned in Issue 30458.

Issue 2 (CRLF in HTTPS host): it seems this doesn’t work in Python as a side effect of Issue 22928 blocking generation of the Host field. But if you add a space you bypass that: "https://host%0D%0A%20SLAVEOF . . .:6379".

Issue 32185 proposes to stop sending IP addresses in the TLS SNI protocol. Maybe this will help; it depends if it will catch IP address strings with with whitespace or if there are other ways to inject invalid hostnames.

Since issue 32185 has been patched, should this one be revisited to see if that solution helped fixed this one?

No activity for 3 years, I close the issue.