Re: CVE-2019-9636 - Can this be exploit over the wire?
> On 5 Sep 2019, at 16:18, Random832 wrote: Thanks for taking the time to reply. > > On Wed, Sep 4, 2019, at 13:36, Barry Scott wrote: >> The conclusion I reached is that the CVE only applies to client code >> that allows a URL in unicode to be entered. >> >> Have I missed something important in the analysis? > > While as I mentioned in my other post I'm not sure if the CVE's analysis of > URL behavior is correct generally, Agreed, would have liked to have had more details and context. > you have missed the fact that an HTML page can provide URLs in unicode, > either with the page itself encoded in UTF-8, or with whatever characters > escaped as XML character references... not only as bytes in IDNA or > percent-escaped hex. The same principle applies to other formats in which > URLs might be interchanged as encoded unicode strings, such as JSON. The fact > that accessing such a URL requires converting the non-ASCII parts to IDNA > (for the domain part) or percent-escaped hex (for other parts) doesn't limit > this to user input. > > https://example.com@bing.com;>like this That gets the unicode version into the app and then the bug can be triggered. In my case this is not a way in as the code does not parse web pages. Barry > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: CVE-2019-9636 - Can this be exploit over the wire?
On Wed, Sep 4, 2019, at 13:36, Barry Scott wrote: > The conclusion I reached is that the CVE only applies to client code > that allows a URL in unicode to be entered. > > Have I missed something important in the analysis? While as I mentioned in my other post I'm not sure if the CVE's analysis of URL behavior is correct generally, you have missed the fact that an HTML page can provide URLs in unicode, either with the page itself encoded in UTF-8, or with whatever characters escaped as XML character references... not only as bytes in IDNA or percent-escaped hex. The same principle applies to other formats in which URLs might be interchanged as encoded unicode strings, such as JSON. The fact that accessing such a URL requires converting the non-ASCII parts to IDNA (for the domain part) or percent-escaped hex (for other parts) doesn't limit this to user input. https://example.com@bing.com;>like this -- https://mail.python.org/mailman/listinfo/python-list
Re: CVE-2019-9636 - Can this be exploit over the wire?
On Wed, Sep 4, 2019, at 13:36, Barry Scott wrote: > I have been looking into CVE-2019-9636 and I'm not sure that > python code that works in bytes is vulnerable to this. I'm not convinced that the CVE (or, at least, the description in the bug report... it's also unclear to me whether this is an accurate example of the CVE) is valid at all. That is, I don't think its suggestion that browsers generally use compatibility normalization in decomposing URLs is correct. I tried the given address "https://example.com\uf...@bing.com; (with actual \uff03 character) in Firefox, Chrome, and Edge, and they all accessed bing.com. -- https://mail.python.org/mailman/listinfo/python-list
CVE-2019-9636 - Can this be exploit over the wire?
I have been looking into CVE-2019-9636 and I'm not sure that
python code that works in bytes is vulnerable to this.
The "trick" that to make the CVE dangerous assumes that you
have a unicode string with \uff03 (FULLWIDTH NUMBER SIGN')
that under NFKC turns into '#'.
The discussion in https://bugs.python.org/issue36216 all the explaination
starts with unicode string.
What I'm interested in what happens if you get the URL as part of a HTML page or
other mechanism.
To that end I made a URL that if the vulnerability is triggered will change
which search
engine is visited.
b'http://google.xn--combing-xr93b.com/fred'
And when I use urlsplit() I get this:
print( urlparse.urlsplit('http://google.xn--combing-xr93b.com/fred') )
SplitResult(scheme='http', netloc='google.xn--combing-xr93b.com',
path='/fred', query='', fragment='')
The netloc is still IDNA encoded so the "trick" did not trigger.
If code then uses that netloc its going to fail to return anything as no
domain name registrar should have register a name with illegal \uff03 in it.
Also this raises an exception:
'google.xn--combing-xr93b.com'.decode('idna')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python2.7/encodings/idna.py", line 193, in decode
result.append(ToUnicode(label))
File "/usr/lib64/python2.7/encodings/idna.py", line 139, in ToUnicode
raise UnicodeError("IDNA does not round-trip", label, label2)
UnicodeError: ('IDNA does not round-trip', 'xn--combing-xr93b',
'com#bing')
The conclusion I reached is that the CVE only applies to client code that
allows a URL
in unicode to be entered.
Have I missed something important in the analysis?
Barry
--
https://mail.python.org/mailman/listinfo/python-list
