They identified a vulnerability in the SHA-3 algorithm library

vulnerability

If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems

A vulnerability has been identified (already listed under CVE-2022-37454) en the implementation of the cryptographic hash function SHA-3 (Keccak), offered in the XKCP package (eXtended Keccak Code Package).

The identified vulnerability can cause a buffer overflow during processing formed data. The problem is due to a bug in the code of a specific implementation of SHA-3, not a vulnerability in the algorithm itself.

The package XKCP is touted as the official implementation of SHA-3, developed with the help of the Keccak development team, and used as the basis for functions to work with SHA-3 in various programming languages ​​(for example, the XKCP code is used in the Python hashlib module, the Ruby digest-sha3 package, and the PHP hash_* functions).

According to the researcher who identified the problem, could use the vulnerability to violate the cryptographic properties of the hash function and find the first and second preimages, as well as determine collisions.

The reason for segmentation fault is that scripts will try 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 to CVE-2019-8741, another vulnerability I found that affected the firmware of over 1.400 billion Apple devices, which also caused a loop infinite.

Also, the creation of a prototype exploit is announced, que allows to achieve code execution when calculating the hash from a specially designed file. The vulnerability can also potentially be used to attack digital signature verification algorithms using SHA-3 (for example, Ed448). Details of the attack methods are expected to be released at a later date, after the general removal of the vulnerability.

This kind of behavior is not supposed to happen in "safe" languages ​​like Python and PHP, since they check that all read and write operations are within the buffer bounds. However, the problem is that the vulnerability is present in the underlying "insecure" C language...

Yet it is unclear how the vulnerability affects existing applications in practice, since for the problem to manifest in code, cyclic hash computation on blocks must be used, and one of the processed blocks must be about 4 GB in size (at least 2^32 – 200 bytes) .

When processing the input data at once (without sequential calculation of the hash by parts), the problem does not appear. As a simpler protection method, it is proposed to limit the maximum size of the data involved in one iteration of the hash calculation.

The vulnerable code was published in January 2011, so it took more than a decade to find this vulnerability. It seems 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 aren't even looking for such vulnerabilities, since neither this vulnerability in XKCP nor the Apple vulnerability mentioned above are eligible for any bug bounty programs!)

Vulnerability is due to an error in block processing of the input data. Due to an incorrect comparison of the values ​​with the type "int", an incorrect size of the outstanding data is determined, which causes the queue to be written out of the allocated buffer.

In particular, it is mentioned that when comparing, the expression «partialBlock + instance->byteIOIndex«, which, with large values ​​of the component parts, led to integer overflow. Also, there was an incorrect typecast "(unsigned int)(dataByteLen - i)" in the code, causing an overflow on systems with a 64-bit size_t type.

Finally if you are interested in knowing more about it, you can check the details in the following link


Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.