Update: This result will appear at CT-RSA 2023. A preprint is now available.
Over the past few months, I’ve been coordinating the disclosure of a new vulnerability that I’ve found. Today is the disclosure date, so I am excited that I can finally talk about what I’ve been working on! The vulnerability has been assigned CVE-2022-37454 and bug reports are available for Python, PHP, PyPy, pysha3, SHA3 for Ruby, and XKCP.
The vulnerability impacts the eXtended Keccak Code Package (XKCP), which is the “official” SHA-3 implementation by its designers. It also impacts various projects that have incorporated this code, such as the Python and PHP scripting languages.
Perhaps the best way to introduce the vulnerability is to give a short proof of concept.
On an older (vulnerable) implementation, the following Python script will generate a segmentation fault:
import hashlib h = hashlib.sha3_224() h.update(b"\x00" * 1) h.update(b"\x00" * 4294967295) print(h.hexdigest())
And the same code in PHP is as follows:
<?php $ctx = hash_init("sha3-224"); hash_update($ctx, str_repeat("\x00", 1)); hash_update($ctx, str_repeat("\x00", 4294967295)); echo hash_final($ctx); ?>
(The scripts use quite a bit of memory, so it may happen that the Out Of Memory (OOM) killer will terminate the process.)
The reason for the segmentation fault is that the scripts will attempt to write more data to a buffer than it can hold. Such a vulnerability is known as a buffer overflow, which OWASP describes as “probably the best-known form of software security vulnerability.”
A small variant of the code will cause an infinite loop: just replace 4294967295 with 4294967296. Note the similarity with CVE-2019-8741, another vulnerability that I found that affected the firmware of over 1.4 billion Apple devices, which also caused an infinite loop.
This type of behavior is not supposed to happen for “safe” languages such as Python and PHP, as they check that all read and write operations are within the bounds of the buffer. However, the problem is that the vulnerability is present in the underlying “unsafe” C language…
I’ve shown how this vulnerability in XKCP can be used to violate the cryptographic properties of the hash function to create preimages, second preimages, and collisions. Moreover, I’ve also shown how a specially constructed file can result in arbitrary code execution, and the vulnerability can also impact signature verification algorithms such as Ed448 that require the use of SHA-3. The details of these attacks will be made public at a later date.
The vulnerable code was released in January 2011, so it took well over a decade for this vulnerability to be found. It appears to be difficult to find vulnerabilities in cryptographic implementations, even though they play a critical role in the overall security of a system. (Perhaps people are not even looking for such vulnerabilities, as neither this vulnerability in XKCP nor the Apple vulnerability mentioned earlier are eligible for any bug bounty program!)
So this is just the beginning… Expect more to come as soon as I can disclose other vulnerabilities that I’ve found!
For comments or questions, feel free to send me an email: