[CVE-2022-37454] SHA3 vulnerability and upcoming Python patches for 3.7 - 3.10
I’m looking for help understanding how Python will release fixes related to the SHA3 critical security vulnerability (CVE-2022-37454). I’ve tried to figure this out myself, but I’m far from a Python expert and I’m not sure where else I should look. Apologies in advance if this is the wrong place to ask - if it is, a redirect to the correct place would be most appreciated. Here’s what I’ve found so far: * Python versions 3.6 through 3.10 appear to be affected * 3.6 is end of life, so no fix is expected * A code fix appears to have been applied to 3.7 through 3.10 https://github.com/python/cpython/issues/98517 * 3.9 and 3.10 by default use OpenSSL1.1.1+ if it’s available, appearing to default to the builtin, vulnerable SHA3 implementation if OpenSSL is not found (if there’s an exception) * 3.9 introduced this change via bpo-37630 in release 3.9.0 beta1 * 3.10 appears to have had this functionality since it was originally released * 3.11 uses tiny_sha3 and AFAICT was never affected by the CVE But what I’m having trouble figuring out is when/how these fixes will become generally available and ready for users of Python to download. * When will patched releases for Python 3.7-3.10 be released? * If pending releases are not in the release pipeline, what other patching opportunities exist? Ultimately I’m trying to set patching expectations for my company’s engineering teams who are still running vulnerable versions of Python. More notes around what i’ve found, in case it helps clarify my questions: From the Python project GitHub I can see gh-98517 to fix the buffer overflow in Python’s internal _sha3 module (CVE-2022-37454) has been committed to the Python 3.7 - 3.10 branches. I understand that for Python releases 3.9 and 3.10 if one is using the OpenSSL 1.1.1+ sha3 modules instead of the internal _sha3 module that is already a mitigation. I also understand that Python 3.11 and later has switched to using tiny_sha3, and no longer relies on the vulnerable _sha3 module. Any information you could point me at would be most helpful. If there is a more ideal forum to raise this question, please redirect me there. Thank you in advance
The patches to 3.6-3.10 have been merged, which means they will go out in the next Python patch release for those updates. ie: https://github.com/python/cpython/issues/98517 You can see the planned schedule of those on https://peps.python.org/pep-0619/ and related similar peps for older python versions (i never remember pep numbers, i just google for "python 3.8 release schedule" to get to such a PEP myself). For 3.9 and earlier which are in "as-needed" security mode and no longer ship binaries I expect we'll get to it within the next month. The patches are public and anyone can apply them on their own. We've got other fixes for other issues coming, so rolling one source only security release for every single issue isn't a great use of time. I personally didn't feel this one was urgent enough to ask anyone to spend time doing an emergency security release as triggering the crash requires someone sending a multi-gigabyte amount of data into a sha3 hash function in a single .update() method call. That seems like a rare code pattern. How many applications ever do that vs doing I/O in smaller chunks with more frequent .update() calls? Linux or other OS distros that bundle Python manage their own patches to their runtimes and their security folks may need to be reminded to pick these patches up if they have not already done so. Their schedules are independent, they're likely to rapidly patch anything they agree with as being a security issue. Distros are also likely the only ones who would apply a backport to 3.6. Anything shipping Python <=3.8 or earlier *should* have an interest in patching. fwiw the forum I would've used for this is the github issue itself as that is the canonical discussion. -gps On Mon, Nov 7, 2022 at 11:52 AM mark_topham--- via Python-Dev < python-dev@python.org> wrote:
I’m looking for help understanding how Python will release fixes related to the SHA3 critical security vulnerability (CVE-2022-37454). I’ve tried to figure this out myself, but I’m far from a Python expert and I’m not sure where else I should look.
Apologies in advance if this is the wrong place to ask - if it is, a redirect to the correct place would be most appreciated.
Here’s what I’ve found so far:
* Python versions 3.6 through 3.10 appear to be affected * 3.6 is end of life, so no fix is expected * A code fix appears to have been applied to 3.7 through 3.10 https://github.com/python/cpython/issues/98517 * 3.9 and 3.10 by default use OpenSSL1.1.1+ if it’s available, appearing to default to the builtin, vulnerable SHA3 implementation if OpenSSL is not found (if there’s an exception) * 3.9 introduced this change via bpo-37630 in release 3.9.0 beta1 * 3.10 appears to have had this functionality since it was originally released * 3.11 uses tiny_sha3 and AFAICT was never affected by the CVE
But what I’m having trouble figuring out is when/how these fixes will become generally available and ready for users of Python to download.
* When will patched releases for Python 3.7-3.10 be released? * If pending releases are not in the release pipeline, what other patching opportunities exist?
Ultimately I’m trying to set patching expectations for my company’s engineering teams who are still running vulnerable versions of Python.
More notes around what i’ve found, in case it helps clarify my questions: From the Python project GitHub I can see gh-98517 to fix the buffer overflow in Python’s internal _sha3 module (CVE-2022-37454) has been committed to the Python 3.7 - 3.10 branches. I understand that for Python releases 3.9 and 3.10 if one is using the OpenSSL 1.1.1+ sha3 modules instead of the internal _sha3 module that is already a mitigation. I also understand that Python 3.11 and later has switched to using tiny_sha3, and no longer relies on the vulnerable _sha3 module.
Any information you could point me at would be most helpful. If there is a more ideal forum to raise this question, please redirect me there.
Thank you in advance _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/K7IYZUGO... Code of Conduct: http://python.org/psf/codeofconduct/
El lun, 7 nov 2022 a las 12:28, Gregory P. Smith (<greg@krypto.org>) escribió:
You can see the planned schedule of those on https://peps.python.org/pep-0619/ and related similar peps for older python versions (i never remember pep numbers, i just google for "python 3.8 release schedule" to get to such a PEP myself).
You can now also use https://peps.python.org/topic/release/ to get all
the release schedule PEPs.
On Nov 7, 2022, at 15:26, Gregory P. Smith <greg@krypto.org> wrote:
The patches to 3.6-3.10 have been merged, which means they will go out in the next Python patch release for those updates. ie: https://github.com/python/cpython/issues/98517\\
I believe Greg meant to type "3.7-3.10", since as noted earlier 3.6 has reached end-of-life. (Of course, downstream distributors of Python 3.6 could choose to provide a patch for 3.6 for their users.) -- Ned Deily nad@python.org -- []
On 07Nov2022 12:26, Gregory P. Smith <greg@krypto.org> wrote:
I personally didn't feel this one was urgent enough to ask anyone to spend time doing an emergency security release as triggering the crash requires someone sending a multi-gigabyte amount of data into a sha3 hash function in a single .update() method call. That seems like a rare code pattern. How many applications ever do that vs doing I/O in smaller chunks with more frequent .update() calls?
As it happens I'm doing some work for a media archiving company and we're looking at recording checksums for archived files. I _may_ well be choosing to mmap a file and calling .update() on the mapping in one go. That said, that's (a) niche and (b) not even written yet. I think I'd still agree that this might be a nonurgent fix (haven't read the CVE properly yet). Cheers, Cameron Simpson <cs@cskk.id.au>
participants (5)
-
Cameron Simpson -
Gregory P. Smith -
Jelle Zijlstra -
mark_topham＠rapid7.com -
Ned Deily