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.

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.

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.

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