Bug 1883632 (CVE-2020-26137)

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