[CVE-2022-37454] Buffer overflow in the _sha3 module in python versions <= 3.10

CVE-2022-37454 affects Python versions prior to 3.11. The fix discussed in XKCP's advisory can be adapted to these versions. The discoverer's writeup contains code that might be turned into regression tests.

Python 3.11 and later switched to using tiny_sha3 in GH-32060, so they should not be affected.

Linked PRs

Scope: When Python is linked against OpenSSL 1.1.1 or later, which is true on many modern systems, the OpenSSL provided sha3 implementation will be used instead of the vulnerable bundled _sha3 XKCP module code.

You can tell if your Python 3.10 or earlier is vulnerable by doing the following:

A potentially vulnerable Python if unpatched looks like this:

>>> import hashlib
>>> hashlib.sha3_224
<class '_sha3.sha3_224'>

A non-vulnerable Python looks like this:

>>> import hashlib
>>> hashlib.sha3_224
<built-in function openssl_sha3_224>

Edit update: Python 3.8 and earlier did not delegate sha3 to OpenSSL regardless of version, so those are vulnerable.

[3.10] gh-98517: Fix buffer overflows in _sha3 module (#98519)

[3.10] pythongh-98517: Fix buffer overflows in _sha3 module (pythonGH…

[3.7] gh-98517: Fix buffer overflows in _sha3 module (GH-98519) (GH-9…

Scope: When Python is linked against OpenSSL 1.1.1 or later, which is true on many modern systems, the OpenSSL provided sha3 implementation will be used instead of the vulnerable bundled _sha3 XKCP module code.

As far as I can see on Fedora, only Python 3.9+ reports <built-in function openssl_sha3_224>. Older Python versions, despite being linked against OpenSSL 1.1.1 or later are still vulnerable.

Scope: When Python is linked against OpenSSL 1.1.1 or later, which is true on many modern systems, the OpenSSL provided sha3 implementation will be used instead of the vulnerable bundled _sha3 XKCP module code.

You can tell if your Python 3.10 or earlier is vulnerable by doing the following:

I don’t think it is correct (at least for the enterprise maintainers dealing with archaeological excavations; however, this is openSUSE/Tumbleweed):

stitny~$ python3.6
Python 3.6.15 (default, Sep 15 2021, 11:41:54) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>> import hashlib
>>> h = hashlib.sha3_224()
>>> hashlib.sha3_224
<class '_sha3.sha3_224'>
>>> h.update(b"\x00" * 1)
>>> h.update(b"\x00" * 4294967295)
fish: Job 1, 'python3.6' terminated by signal SIGSEGV (Address boundary error)
stitny~$

and even

stitny~$ python3.8
Python 3.8.15 (default, Oct 19 2022, 07:18:07) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.sha3_224
<class '_sha3.sha3_224'>
>>> h = hashlib.sha3_224()
>>> h.update(b"\x00" * 1)
>>> h.update(b"\x00" * 4294967295)
fish: Job 1, 'python3.8' terminated by signal SIGSEGV (Address boundary error)
stitny~$

So, you are right, linking against the modern OpenSSL is the key.

Scope: When Python is linked against OpenSSL 1.1.1 or later, which is true on many modern systems, the OpenSSL provided sha3 implementation will be used instead of the vulnerable bundled _sha3 XKCP module code.

Hmm, it is not that simple: see my example with Python 3.6 on openSUSE. See also (the same goes for our Python 3.8):

stitny~$ python3.6
Python 3.6.15 (default, Sep 15 2021, 11:41:54) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.1.1q  5 Jul 2022'
>>>

openssl sha3 delegation was added in commit d5b3f6b, which is 3.9 and later python I think.

@tiran

openssl sha3 delegation was added in commit d5b3f6b, which is 3.9 and later python I think.

Hmm, that makes me wonder, @tiran, how hopeless do you think it would be to port that pull request to 3.8 and 3.6? Did the underlying code completely changed between the versions or is it more or less the same? I really don’t like bundled implementations of security algorithms.

Our 3.7 and 3.8 branches will get the patch merged, see the PRs above. 3.6 is EOL but it is trivial to apply the change to older _sha3 supporting releases for distributors with a need to do so on their own.

[3.8] gh-98517: Fix buffer overflows in _sha3 module (GH-98519) (#98527)

[3.9] gh-98517: Fix buffer overflows in _sha3 module (GH-98519) (#98526)

Update python38 to version 3.8.15 / rev 29 via SR 1032060

I created https://python-security.readthedocs.io/vuln/sha3-buffer-overflow.html to track this vulnerability.

Everything was merged. Closing. If you don't see this fix backported into your favorite OS distro that ships their own Python packages, reach out to that distro's security reporting process. Otherwise these will be part of the next planned regular patch releases of all impacted Python versions. https://peps.python.org/pep-0619/ for example. (there's a similar PEP for each version)

package/python3: fix CVE-2022-37454

Navigation Menu

Repository navigation

[CVE-2022-37454] Buffer overflow in the _sha3 module in python versions <= 3.10 #98517

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[CVE-2022-37454] Buffer overflow in the _sha3 module in python versions <= 3.10 #98517

Description

Linked PRs

Activity

gpshead commented on Oct 21, 2022

hroncok commented on Oct 25, 2022

mcepl commented on Oct 25, 2022

mcepl commented on Oct 25, 2022

msmeissn commented on Oct 25, 2022

mcepl commented on Oct 25, 2022

gpshead commented on Oct 26, 2022

vstinner commented on Nov 4, 2022

gpshead commented on Nov 7, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions