[issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache poisoning - `; ` as a query args separator
Riccardo Schirone added the comment: > So far, we at openSUSE had to package at least SQLAlchemy, Twisted, yarl and > furl. The author of the first one acknowledged use of semicolon as a bug. I > don't think it was so bad. Did you upstream fixes for those packages? Asking because if this is considered a vulnerability in Python, it should be considered a vulnerability for every other tool/library that accept `;` as separator. For example, Twisted seems to have a parse_qs method in web/http.py file that splits by both `;` and `&`. Again, I feel like we are blaming the wrong piece of the stack, unless proxies are usually ignoring some arguments (e.g. utm_*) as part of the cache key, by default or in a very easy way. -- ___ Python tracker <https://bugs.python.org/issue42967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache poisoning - `; ` as a query args separator
Riccardo Schirone added the comment: This CVE was reported against Python, however it does not seem to be Python's fault for supporting the `;` separator, which was a valid separator for older standards. @AdamGold for this issue to become a real security problem, it seems that the proxy has to be configured to ignore certain parameters in the query. For NGINX and Varnish proxies mentioned in the article it seems that by default they use the entire request path, host included, and other things as cache key. For NGINX in particular I could find some snippets online to manipulate the query arguments and split them in arguments, so to remove the "utm_*" arguments, however this does not seem a standard(or at least default) behaviour, nor something easily supported. I think that if that is the case and a user has to go out of his way to configure the (wrong) splitting of arguments in the proxy, it is not fair to blame python for accepting `;` as separator and assigning a CVE against it may cause confusion. For distributions this is problematic as they have 2 choices: 1) "fix" python but with the risk of breaking user's programs/scripts relying on the previous API 2) keep older version/unpatched python so that user's programs still work, but with a python version "vulnerable" to this CVE. None of these options is really ideal, especially if the problem is somewhere else. @AdamGold Could you elaborate a bit more on how common it is and how much configuration is required for proxies to make `;` a problem in python? -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue42967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40338] [Security] urllib and anti-slash (\) in the hostname
Riccardo Schirone added the comment: I agree I don't see a clear vulnerability here. -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue40338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38576] CVE-2019-18348: CRLF injection via the host part of the url passed to urlopen()
Riccardo Schirone added the comment: The glibc issue mentioned in the first comment is CVE-2016-10739 . -- ___ Python tracker <https://bugs.python.org/issue38576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)
Riccardo Schirone added the comment: I have created https://bugs.python.org/issue38576 to address CVE-2019-18348. @gregory.p.smith if you have particular complains about these CVEs feel free to let me know (even privately). I think the security impact of these flaws is: an application that relies on urlopen/HTTPConnection/etc. where either the query part, the path part or the host part are user-controlled, could be exploited to send unintended HTTP headers to other hosts (maybe services that would not be directly reachable by the user). FYI, there were some good replies to that CVE talk, one of which is https://grsecurity.net/reports_of_cves_death_greatly_exaggerated . -- ___ Python tracker <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38576] CVE-2019-18348 CRLF injection via the host part of the url passed to urlopen()
New submission from Riccardo Schirone :
Copy-pasted from https://bugs.python.org/issue30458#msg347282
The commit b7378d77289c911ca6a0c0afaf513879002df7d5 is incomplete: it doesn't
seem to check for control characters in the "host" part of the URL, only in the
"path" part of the URL. Example:
---
try:
from urllib import request as urllib_request
except ImportError:
import urllib2 as urllib_request
import socket
def bug(*args):
raise Exception(args)
# urlopen() must not call create_connection()
socket.create_connection = bug
urllib_request.urlopen('http://127.0.0.1\r\n\x20hihi\r\n :11211')
---
The URL comes from the first message of this issue:
https://bugs.python.org/issue30458#msg294360
Development branches 2.7 and master produce a similar output:
---
Traceback (most recent call last):
...
Exception: (('127.0.0.1\r\n hihi\r\n ', 11211), ..., None)
---
So urllib2/urllib.request actually does a real network connection (DNS query),
whereas it should reject control characters in the "host" part of the URL.
***
A second problem comes into the game. Some C libraries like glibc strip the end
of the hostname (strip at the first newline character) and so HTTP Header
injection is still possible is this case:
https://bugzilla.redhat.com/show_bug.cgi?id=1673465
***
According to the RFC 3986, the "host" grammar doesn't allow any control
character, it looks like:
host = IP-literal / IPv4address / reg-name
ALPHA (letters)
DIGIT (decimal digits)
unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
reg-name = *( unreserved / pct-encoded / sub-delims )
IP-literal= "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address =6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::"h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
CVE-2019-18348 was assigned to this flaw, which is similar to CVE-2019-9947 and
CVE-2019-9740 but it is about the *host* part of a url.
--
messages: 355294
nosy: rschiron
priority: normal
severity: normal
status: open
title: CVE-2019-18348 CRLF injection via the host part of the url passed to
urlopen()
type: security
___
Python tracker
<https://bugs.python.org/issue38576>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)
Riccardo Schirone added the comment: CVE-2019-18348 has been assigned to the issue explained in https://bugs.python.org/issue30458#msg347282 . Maybe a separate bug for it would be better though. CVE-2019-18348 is about injecting CRLF in HTTP requests through the *host* part of a URL. -- ___ Python tracker <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
Riccardo Schirone added the comment: CVE-2019-16056 has been assigned to this issue. See https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16056 . -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue34155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)
Riccardo Schirone added the comment: Will the flaw outlined in https://bugs.python.org/issue30458#msg347282 be fixed in python itself? If so, I think a CVE for python should be requested to MITRE (I can request one, in that case). Moreover, does it make sense to create a new bug to track the new issue? This bug already references 3 CVEs and it would probably just create more confusion to reference a 4th. What do you think? -- ___ Python tracker <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35121] Cookie domain check returns incorrect results
Riccardo Schirone added the comment: CVE-2018-20852 has been assigned to this flaw. -- ___ Python tracker <https://bugs.python.org/issue35121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)
Riccardo Schirone added the comment: > > A second problem comes into the game. Some C libraries like glibc strip the > > end of the hostname (strip at the first newline character) and so HTTP > > Header injection is still possible is this case: > > https://bugzilla.redhat.com/show_bug.cgi?id=1673465 > The bug link raises permission error. Does fixing the host part fix this > issue too since there won't be any socket connection made? Is it possible to > have a Python reproducer of this issue? I think this was supposed to refer to CVE-2016-10739 (https://bugzilla.redhat.com/show_bug.cgi?id=1347549) -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37463] socket.inet_aton IP parsing issue in ssl.match_hostname
Riccardo Schirone added the comment: As far as I know you can't request a hostname with spaces in it (which seems to be a precondition to trigger this bug) so I think an attacker cannot even create a malicious CA that would be mistakenly accepted by match_hostname. -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue37463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35121] Cookie domain check returns incorrect results
Riccardo Schirone added the comment: Did anybody request a CVE for this issue? I think it deserves one as it is a security issue and it may leak cookies to wrong domains. Does anybody have anything against assigning a CVE to this issue? If not, I would try to get one from MITRE. -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue35121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36742] CVE-2019-10160: urlsplit NFKD normalization vulnerability in user:password@
Riccardo Schirone added the comment: > CVE-2019-10160 has been assigned by Red Hat to this flaw. For clarity, CVE-2019-10160 has been assigned to the bug introduced with the fix for the functional regression mentioned in this bug, and not to the bug itself explained in the first comment. See https://bugzilla.redhat.com/show_bug.cgi?id=1718388 for more details about it. -- ___ Python tracker <https://bugs.python.org/issue36742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36742] CVE-2019-10160: urlsplit NFKD normalization vulnerability in user:password@
Riccardo Schirone added the comment: The fix for python-2.7 (https://github.com/python/cpython/pull/13815/files#diff-b577545d73dd0cdb2c337a4c5f89e1d7R183) causes errors when netloc contains characters that can't be encoded by 'ascii' codec. You can see it by doing: >>> netloc = u'example.com\uf...@bing.com' >>> raise ValueError(u"netloc '" + netloc + u"' contains invalid characters >>> under NFKC normalization") Traceback (most recent call last): File "", line 1, in ValueError: >>> str(netloc) Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character u'\uff03' in position 11: ordinal not in range(128) I suggest we use `repr(netloc)` instead of `netloc` in the ValueError message. -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue36742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
