A security issue was found in python-urllib3. HTTPConnection.request() does not properly validate CRLF sequences in the HTTP request method, potentially allowing to manipulate the request by injecting additional HTTP headers. Note that CVE-2020-26116 is strictly related to this bug, as the same flaw was reported in both urllib3 and built-in modules httplib/http.client. References: * https://bugs.python.org/issue39603 Upstream patch PR (merged upstream): * https://github.com/urllib3/urllib3/pull/1800 Upstream commit: * https://github.com/urllib3/urllib3/commit/1dd69c5c5982fae7c87a620d487c2ebf7a6b436b
Created python-pip tracking bugs for this issue: Affects: epel-6 [bug 1883871] Affects: fedora-all [bug 1883873] Created python-pip-epel tracking bugs for this issue: Affects: epel-7 [bug 1883872] Created python3-urllib3 tracking bugs for this issue: Affects: epel-all [bug 1883870]
Created python-urllib3 tracking bugs for this issue: Affects: fedora-all [bug 1883876]
As for the pip bugs, do we know where in pip can an attacker control the HTTP method used? AFAIK, pip itself uses GET and POST but doesn't let you do arbitrary requests.
In reply to comment #13: > As for the pip bugs, do we know where in pip can an attacker control the > HTTP method used? AFAIK, pip itself uses GET and POST but doesn't let you do > arbitrary requests. Hi Petr, we only have a reproducer for urllib3 and httplib/http.client. I created those bugs to account for the fact that pip is using a vulnerable version of urllib3 (and ideally it should be fixed). I thought this might lead to some troubles, but honestly I don't know if/how this could be exploited in pip. If there's no way for an external attacker to control the HTTP method, we can surely consider closing those bugs as NOTABUG. Thanks.
I've done an investigation of this security issue. The vulnerable method is `putrequest` from `HTTPConnection` class from `http.client` module in Python standard library. This issue is already fixed upstream for all supported Python versions. `HTTPConnection` class in urllib3 inherits from the mentioned `HTTPConnection` class from the standard library which means that fixing the vulnerability only in Python itself should be enough. But, as far as I understand, the fix is implemented also in urllib3 because: * the library doesn't want to wait for the next Python release and * it still maintains support for Python 2.7 where this vulnerability won't be fixed in Python itself (upstream). Pip bundles its own versions of requests and urllib3 and uses only the high level API of requests. I haven't found any possible way how a pip user migh modify the HTTP method when sending a HTTP request. And even if I would be wrong, we are going to fix this vulnerability in Python interpreters so the chain pip > requests > urllib3 > http.client will be fixed all at once. Therefore I think we can close all pip bugs as notabug.
To prove what I said in the previous comment, here is an example of how the fix in Python itself fixes also python-urllib3 package and urllib3 bundled in pip. I'm using the reproducer from the security team. # python34-3.4.10-6.el7.x86_64 (vulnerable) $ python3.4 poc.py <no error> <second terminal>$ nc -l -p 3333 GET / HTTP/1.1 X-INJECTED: HEADER REMAINDER: / HTTP/1.1 Host: localhost:3333 Accept-Encoding: identity The situation is the same when I use the bundled urllib3 in pip via `PYTHONPATH=/usr/lib/python3.4/site-packages/pip/_vendor/requests/packages/ python3.4 poc.py` # python34-3.4.10-7.el7.x86_64 (fixed, update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-bd6a96cd24) $ python3.4 poc.py Traceback (most recent call last): File "poc.py", line 12, in <module> info = pool_manager.request(method, url) File "/usr/lib/python3.4/site-packages/urllib3/request.py", line 80, in request method, url, fields=fields, headers=headers, **urlopen_kw File "/usr/lib/python3.4/site-packages/urllib3/request.py", line 171, in request_encode_body return self.urlopen(method, url, **extra_kw) File "/usr/lib/python3.4/site-packages/urllib3/poolmanager.py", line 330, in urlopen response = conn.urlopen(method, u.request_uri, **kw) File "/usr/lib/python3.4/site-packages/urllib3/connectionpool.py", line 672, in urlopen chunked=chunked, File "/usr/lib/python3.4/site-packages/urllib3/connectionpool.py", line 387, in _make_request conn.request(method, url, **httplib_request_kw) File "/usr/lib64/python3.4/http/client.py", line 1154, in request self._send_request(method, url, body, headers) File "/usr/lib64/python3.4/http/client.py", line 1189, in _send_request self.putrequest(method, url, **skips) File "/usr/lib64/python3.4/http/client.py", line 1011, in putrequest self._validate_method(method) File "/usr/lib64/python3.4/http/client.py", line 1107, in _validate_method % (method, match.group())) ValueError: method can't contain control characters. 'GET / HTTP/1.1\r\nX-INJECTED: HEADER\r\nREMAINDER:' (found at least '\r') $ PYTHONPATH=/usr/lib/python3.4/site-packages/pip/_vendor/requests/packages/ python3.4 poc.py Traceback (most recent call last): File "poc.py", line 12, in <module> info = pool_manager.request(method, url) File "/usr/lib/python3.4/site-packages/pip/_vendor/requests/packages/urllib3/request.py", line 73, in request **urlopen_kw) File "/usr/lib/python3.4/site-packages/pip/_vendor/requests/packages/urllib3/request.py", line 151, in request_encode_body return self.urlopen(method, url, **extra_kw) File "/usr/lib/python3.4/site-packages/pip/_vendor/requests/packages/urllib3/poolmanager.py", line 166, in urlopen response = conn.urlopen(method, u.request_uri, **kw) File "/usr/lib/python3.4/site-packages/pip/_vendor/requests/packages/urllib3/connectionpool.py", line 578, in urlopen chunked=chunked) File "/usr/lib/python3.4/site-packages/pip/_vendor/requests/packages/urllib3/connectionpool.py", line 362, in _make_request conn.request(method, url, **httplib_request_kw) File "/usr/lib64/python3.4/http/client.py", line 1154, in request self._send_request(method, url, body, headers) File "/usr/lib64/python3.4/http/client.py", line 1189, in _send_request self.putrequest(method, url, **skips) File "/usr/lib64/python3.4/http/client.py", line 1011, in putrequest self._validate_method(method) File "/usr/lib64/python3.4/http/client.py", line 1107, in _validate_method % (method, match.group())) ValueError: method can't contain control characters. 'GET / HTTP/1.1\r\nX-INJECTED: HEADER\r\nREMAINDER:' (found at least '\r')
Created python-urllib3 tracking bugs for this issue: Affects: openstack-rdo [bug 1887224]
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.7 EUS Via RHSA-2020:4299 https://access.redhat.com/errata/RHSA-2020:4299
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-26137
Statement: * Red Hat OpenShift Container Platform (OCP) 4 delivers the python-urllib3 package which includes vulnerable version of urllib3 module, however from OCP 4.6 the python-urllib3 package is no longer shipped and will not be fixed. * In Red Hat OpenStack Platform, because the flaw has a lower impact and the fix would require a substantial amount of development, no update will be provided at this time for the RHOSP python-urllib3 package. Note: Versions of `python-pip` are marked as not affected because there is no way for a pip user to control the HTTP request method.
(In reply to Summer Long from comment #26) > * Red Hat OpenShift Container Platform (OCP) 4 delivers the python-urllib3 > package which includes vulnerable version of urllib3 module, however from > OCP 4.6 the python-urllib3 package is no longer shipped and will not be > fixed. OpenShift ships several container images which pull in RHEL8's python[3]-urllib3: the ironic* and kuryr* containers in all 4.y versions, and ansible-operator and its dependants in 4.6+.
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.5 Via RHSA-2021:0034 https://access.redhat.com/errata/RHSA-2021:0034
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 3.11 Via RHSA-2021:0079 https://access.redhat.com/errata/RHSA-2021:0079
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:1631 https://access.redhat.com/errata/RHSA-2021:1631
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:1761 https://access.redhat.com/errata/RHSA-2021:1761
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2022:5235 https://access.redhat.com/errata/RHSA-2022:5235