Om de utnyttjas kan dessa brister tillåta angripare att få obehörig åtkomst till känslig information eller i allmänhet orsaka problem
En sårbarhet har identifierats (redan listad under CVE-2022-37454) en implementeringen av den kryptografiska hashfunktionen SHA-3 (Keccak), erbjuds i XKCP-paketet (eXtended Keccak Code Package).
Den identifierade sårbarheten kan orsaka buffertspill under bearbetning av bildade data. Problemet beror på en bugg i koden för en specifik implementering av SHA-3, inte en sårbarhet i själva algoritmen.
El paquete XKCP utses som den officiella implementeringen av SHA-3, utvecklad med hjälp av Keccaks utvecklingsteam, och används som grund för funktioner för att arbeta med SHA-3 i olika programmeringsspråk (exempelvis används XKCP-koden i Python hashlib-modulen, Ruby digest-sha3-paketet och PHP hash_*-funktionerna).
Enligt forskaren som identifierade problemet, kan använda sårbarheten för att bryta mot de kryptografiska egenskaperna av hashfunktionen och hitta den första och andra förbilden, samt fastställa kollisioner.
Anledningen till segmenteringsfel är att skript kommer att försöka skriva mer data till en buffert än vad det kan hålla. En sådan sårbarhet är känd som ett buffertspill, vilket OWASP beskriver som "förmodligen den mest kända formen av mjukvarusäkerhetssårbarhet."
En liten variant av koden kommer att orsaka en oändlig loop: ersätt bara 4294967295 med 4294967296. Notera likheten med CVE-2019-8741, en annan sårbarhet jag hittade som påverkade den fasta programvaran på över 1.400 miljarder Apple-enheter, vilket också orsakade en oändlig loop.
Också, skapandet av en prototyp exploatering tillkännages, que gör det möjligt att uppnå kodexekvering vid beräkning av hash från en specialdesignad fil. Sårbarheten kan även potentiellt användas för att attackera digitala signaturverifieringsalgoritmer med SHA-3 (till exempel Ed448). Detaljer om attackmetoderna förväntas släppas vid ett senare tillfälle, efter det allmänna avlägsnandet av sårbarheten.
Den här typen av beteende är inte tänkt att hända i "säkra" språk som Python och PHP, eftersom de kontrollerar att alla läs- och skrivoperationer ligger inom buffertgränserna. Problemet är dock att sårbarheten finns i det underliggande "osäkra" C-språket...
Än det är oklart hur sårbarheten påverkar befintliga applikationer i praktiken, eftersom för att problemet ska manifestera sig i kod måste cyklisk hashberäkning på block användas, och ett av de bearbetade blocken måste vara cirka 4 GB i storlek (minst 2^32 – 200 byte) .
När du bearbetar indata på en gång (utan sekventiell beräkning av hashen efter delar) uppstår inte problemet. Som en enklare skyddsmetod föreslås en begränsning av den maximala storleken på de data som ingår i en iteration av hashberäkningen.
Den sårbara koden publicerades i januari 2011, så det tog mer än ett decennium att hitta denna sårbarhet. Det verkar vara svårt att hitta sårbarheter i kryptografiska implementeringar, även om de spelar en avgörande roll för den övergripande säkerheten i ett system. (Kanske människor inte ens letar efter sådana sårbarheter, eftersom varken denna sårbarhet i XKCP eller Apple-sårbarheten som nämns ovan är kvalificerade för några bugg-bounty-program!)
Sårbarhet beror på ett fel i blockbearbetningen av indata. På grund av en felaktig jämförelse av värdena med typen "int" bestäms en felaktig storlek på utestående data, vilket gör att kön skrivs ut ur den tilldelade bufferten.
Särskilt nämns att vid jämförelse uttrycket «partialBlock + instans->byteIOIndex«, vilket, med stora värden på komponentdelarna, ledde till heltalsspill. Det fanns också en felaktig typcast "(unsigned int)(dataByteLen - i)" i koden, vilket orsakade ett spill på system med en 64-bitars size_t-typ.
Slutligen om du är intresserad av att veta mer om detkan du kontrollera detaljerna i följande länk.