En sårbarhet (CVE-3-2022) har identifierats i implementeringen av den kryptografiska hashfunktionen SHA-37454 (Keccak) som erbjuds i XKCP-paketet (eXtended Keccak Code Package), vilket kan leda till ett buffertspill under bearbetningen av vissa formaterade data. Problemet orsakas av en bugg i koden för en specifik implementering av SHA-3, och inte av en sårbarhet i själva algoritmen. XKCP-paketet utses som den officiella implementeringen av SHA-3, utvecklad med input från Keccak-utvecklingsteamet och används som grund för SHA-3-funktioner i olika programmeringsspråk (exempelvis används XKCP-kod i Python hashlib) modulen, Ruby digest-paketet sha3 och PHP hash_* funktioner).
Enligt forskaren som identifierade problemet kunde han använda sårbarheten för att bryta mot hashfunktionens kryptografiska egenskaper och hitta den första och andra förbilden, samt upptäcka kollisioner. Dessutom tillkännagavs att en prototypexploatering skulle skapas som skulle tillåta att kod exekveras vid beräkning av hash för en specialdesignad fil. Sårbarheten kan också potentiellt användas för att attackera digitala signaturverifieringsalgoritmer som använder SHA-3 (till exempel Ed448). Detaljer om attackmetoderna är planerade att publiceras senare, efter att sårbarheten har eliminerats överallt.
Det är ännu inte klart hur mycket sårbarheten påverkar befintliga applikationer i praktiken, eftersom för att problemet ska visa sig i koden måste cykliska hashberäkningar i block användas och ett av de bearbetade blocken måste vara cirka 4 GB stort (minst. 2^32 - 200 byte). När du bearbetar indata på en gång (utan att sekventiellt beräkna hashen i delar) uppstår inte problemet. Som den enklaste skyddsmetoden föreslås en begränsning av den maximala storleken på data som ingår i en iteration av hashberäkningen.
Sårbarheten orsakas av ett fel vid blockbearbetning av indata. På grund av felaktig jämförelse av värden med typen "int" bestäms den felaktiga storleken på väntande data, vilket leder till att svansen skrivs bortom den tilldelade bufferten. I synnerhet använde jämförelsen uttrycket "partialBlock + instans->byteIOIndex", vilket ledde till heltalsspill för stora värden av de ingående delarna. Dessutom fanns det en felaktig typ av cast "(unsigned int)(dataByteLen - i)" i koden, vilket orsakade ett spill på system med en 64-bitars size_t-typ.
Exempelkod som orsakar spill: import hashlib h = hashlib.sha3_224() m1 = b"\x00" * 1; m2 = b"\x00″ * 4294967295; h.update(m1) h.update(m2) print(h.hexdigest())
Källa: opennet.ru