{"id":105350,"date":"2022-10-21T09:36:42","date_gmt":"2022-10-21T07:36:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-biblioteke-s-osnovnoj-realizacziej-algoritma-sha-3"},"modified":"2022-10-21T09:36:42","modified_gmt":"2022-10-21T07:36:42","slug":"uyazvimost-v-biblioteke-s-osnovnoj-realizacziej-algoritma-sha-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/uyazvimost-v-biblioteke-s-osnovnoj-realizacziej-algoritma-sha-3","title":{"rendered":"Vulnerability in the library implementing the SHA-3 algorithm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
A vulnerability (CVE-2022-37454) has been identified in the implementation of the SHA-3 (Keccak) cryptographic hash function offered in the XKCP (eXtended Keccak Code Package), which may lead to a buffer overflow during the processing of specifically formatted data. The issue is caused by a bug in the specific implementation of SHA-3, rather than a vulnerability in the algorithm itself. The XKCP package is presented as the official implementation of SHA-3, developed with the participation of the Keccak development team and used as a basis for SHA-3 functions in various programming languages (for example, the XKCP code is utilized in the Python module hashlib, Ruby package digest-sha3, and PHP functions hash_*). <\/p>\n
According to the researcher who discovered the issue, they were able to exploit the vulnerability to break the cryptographic properties of the hash function, allowing the discovery of the first and second preimages, as well as identifying collisions. Furthermore, a prototype exploit has been created, which allows for code execution when hashing a specially formatted file. Potentially, the vulnerability could also be used to attack digital signature verification algorithms that utilize SHA-3 (for instance, Ed448). Details on the methods for conducting attacks are expected to be published later, after the vulnerability has been mitigated widely. <\/p>\n
It remains unclear how the vulnerability affects existing applications in practice, as the problem in the code must involve cyclic hashing of blocks, and one of the processed blocks must be approximately 4 GB in size (at least 2^32 \u2014 200 bytes). When processing input data all at once (without sequentially hashing in parts), the issue does not manifest. A simple method of protection is suggested: limit the maximum size of the data involved in a single iteration of hashing. <\/p>\n
The vulnerability is caused by an error in the block processing of input data. Due to an incorrect comparison of values with the type 'int', the expected size of the data to be processed is incorrectly determined, leading to the tail being written beyond the allocated buffer. In particular, the expression 'partialBlock + instance->byteIOIndex' was used for comparison, which caused integer overflow for large values of its components. Furthermore, the code contained an invalid type cast '(unsigned int)(dataByteLen - i)', leading to overflow on systems with a 64-bit size_t type. <\/p>\n