The package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9.0 and before 3.9.2 are vulnerable to Web Cache Poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a vector called parameter cloaking. When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server. This can result in malicious requests being cached as completely safe ones, as the proxy would usually not see the semicolon as a separator, and therefore would not include it in a cache key of an unkeyed parameter. Reference: https://bugs.python.org/issue42967
Created mingw-python3 tracking bugs for this issue: Affects: fedora-all [bug 1928912] Created python2.7 tracking bugs for this issue: Affects: fedora-all [bug 1928916] Created python26 tracking bugs for this issue: Affects: fedora-all [bug 1928906] Created python27 tracking bugs for this issue: Affects: fedora-all [bug 1928913] Created python3 tracking bugs for this issue: Affects: fedora-all [bug 1928907] Created python3.10 tracking bugs for this issue: Affects: fedora-all [bug 1928908] Created python3.5 tracking bugs for this issue: Affects: fedora-all [bug 1928917] Created python3.6 tracking bugs for this issue: Affects: fedora-all [bug 1928918] Created python3.7 tracking bugs for this issue: Affects: fedora-all [bug 1928919] Created python3.8 tracking bugs for this issue: Affects: fedora-all [bug 1928920] Created python3.9 tracking bugs for this issue: Affects: fedora-all [bug 1928921] Created python34 tracking bugs for this issue: Affects: epel-all [bug 1928923] Affects: fedora-all [bug 1928909] Created python35 tracking bugs for this issue: Affects: fedora-all [bug 1928910] Created python36 tracking bugs for this issue: Affects: fedora-all [bug 1928911] Created python37 tracking bugs for this issue: Affects: fedora-all [bug 1928914] Created python39 tracking bugs for this issue: Affects: fedora-all [bug 1928915]
FEDORA-2021-e062e195e1 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-7fa9dc84d4 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
This issue only becomes a real security flaw when there is already another flaw in a web application, that for example allows to have XSS or similar. Otherwise, even if the cache might return different results, users would not be impacted by this from a security point of view. However, it is better to have the proxy (implementing the cache) and the server in sync with regards to parsing HTTP responses.
External References: https://snyk.io/vuln/SNYK-UPSTREAM-PYTHONCPYTHON-1074933
Upstream fixes: https://github.com/python/cpython/commit/fcbe0cb04d35189401c0c880ebfb4311e952d776 https://github.com/python/cpython/commit/a2f0654b0a5b4c4f726155620002cc1f5f2d206a Upstream Django fix: https://github.com/django/django/commit/be8237c7cce24b06aabde0b97afce98ddabbe3b6 [3.2.x]
Created python-django tracking bugs for this issue: Affects: epel-all [bug 1931539] Affects: fedora-all [bug 1931542] Created python-django16 tracking bugs for this issue: Affects: epel-all [bug 1931540] Created python-django3 tracking bugs for this issue: Affects: epel-all [bug 1931541]
Related fixes for python-django also released in: * Django 3.2b1 * Django 3.1.7 * Django 3.0.13 * Django 2.2.19
Created python-django tracking bugs for this issue: Affects: openstack-rdo [bug 1932703]
> The default for the proxy is to accept only "&" parameter separator in URLs, but the > default of Python in the affected versions was to also accept ";" as a URL parameter > separator. Therefore the default configuration of Python and the proxy can lead to > Web Cache Poisoning and leak sensitive data. The issue is that this is only the default for *some* proxies, not all. To fix the CVE, the behavior needs to match in both the application and in any & all proxies used, which might all come from different vendors.
The upstream fix breaks backwards compatibility, which we want to avoid in RHEL. Especially since there are applications that use the ';' separator -- the proper fix for those would be to configure both the proxy and the app to use ';'. So, here is our current plan about what to do: - Python 3.9: Use the upstream behavior (split only on '&' by default, pass separator=';' to split on ';', no option to split on both). This should be a 0-day update. The python39 module isn't released yet, so there's no compatiblity break. - Python 3.8: - backport the `separator` argument, so users can choose to split either on '&' or on ';' eplicitly - default changes to upstream (only split on '&') - by setting an environment variable, you can restore the old behavior (split on both '&' or ';' by default) or choose to split on ';' by default. - Python 3.6 and 2.7: - backport the `separator` argument, so users can choose to split either on '&' or on ';' eplicitly - by setting an environment variable, you can choose the default separator ('&', ';', or both) - if the variable is not set, the default stays as in older versions (split on both '&' and ';') - if the variable is not set AND `separator` is not given AND the input includes ';', trigger a warning about the unsafe behavior. Ideally, link to a KB article in the warning. The environment variable would be: PYTHON_URLLIB_QS_SEPARATOR=unsafe PYTHON_URLLIB_QS_SEPARATOR=';' PYTHON_URLLIB_QS_SEPARATOR='&'
> An alternative to "unsafe" would be to accept "&;" and ";&". A concern with "unsafe" is that it's only unsafe in certain specific configurations. Sure, but if future versions of Python fix the CVE by not accepting both separators at all. I'd rather push people toward selecting just one. > Should the warning be emitted only when you try to parse a query string with a semicolon? There's a balance between that and spamming warnings all the time. I don't know which would be better.
Tomáš raised one more consideration: should the default be configurable with a config file, rather than just an envorinment variable. That way, we could make CVE scanners satisfied that the issue is mitigated across a system. Would that be useful?
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:1633 https://access.redhat.com/errata/RHSA-2021:1633
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-2021-23336
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.7 EUS Via RHSA-2021:3252 https://access.redhat.com/errata/RHSA-2021:3252
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.7 EUS Via RHSA-2021:3254 https://access.redhat.com/errata/RHSA-2021:3254
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4151 https://access.redhat.com/errata/RHSA-2021:4151
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4162 https://access.redhat.com/errata/RHSA-2021:4162
We have prepared a Knowledge Base article about this CVE and the possibly backwards incompatible fixes for it: https://access.redhat.com/articles/5860431