Hvis de utnyttes, kan disse feilene tillate angripere å få uautorisert tilgang til sensitiv informasjon eller generelt forårsake problemer
En sårbarhet er identifisert (allerede oppført under CVE-2022-37454) en implementeringen av den kryptografiske hash-funksjonen SHA-3 (Keccak), tilbys i XKCP-pakken (eXtended Keccak Code Package).
Den identifiserte sårbarheten kan forårsake bufferoverløp under behandling av dannede data. Problemet skyldes en feil i koden til en spesifikk implementering av SHA-3, ikke en sårbarhet i selve algoritmen.
El paquete XKCP er utpekt som den offisielle implementeringen av SHA-3, utviklet med hjelp av Keccak utviklingsteam, og brukes som grunnlag for funksjoner for å arbeide med SHA-3 i forskjellige programmeringsspråk (for eksempel brukes XKCP-koden i Python hashlib-modulen, Ruby digest-sha3-pakken og PHP hash_*-funksjonene).
Ifølge forskeren som identifiserte problemet, kan bruke sårbarheten til å krenke de kryptografiske egenskapene av hash-funksjonen og finne det første og andre forbildet, samt bestemme kollisjoner.
Årsaken til segmenteringsfeil er at skript vil prøve å skrive mer data til en buffer enn det kan holde. En slik sårbarhet er kjent som et bufferoverløp, som OWASP beskriver som "sannsynligvis den mest kjente formen for sikkerhetssårbarhet for programvare."
En liten variant av koden vil forårsake en uendelig sløyfe: bare bytt ut 4294967295 med 4294967296. Legg merke til likheten med CVE-2019-8741, en annen sårbarhet jeg fant som påvirket fastvaren til over 1.400 milliarder Apple-enheter, som også forårsaket en løkke uendelig.
Også, kunngjøres opprettelsen av en prototypeutnyttelse, que gjør det mulig å oppnå kodekjøring ved beregning av hashen fra en spesialdesignet fil. Sårbarheten kan også potensielt brukes til å angripe digitale signaturverifiseringsalgoritmer ved å bruke SHA-3 (for eksempel Ed448). Detaljer om angrepsmetodene forventes å bli utgitt på et senere tidspunkt, etter generell fjerning av sårbarheten.
Denne typen oppførsel er ikke ment å skje på "sikre" språk som Python og PHP, siden de sjekker at alle lese- og skriveoperasjoner er innenfor buffergrensene. Problemet er imidlertid at sårbarheten er tilstede i det underliggende "usikre" C-språket...
Ennå det er uklart hvordan sårbarheten påvirker eksisterende applikasjoner i praksis, siden for at problemet skal manifestere seg i kode, må syklisk hash-beregning på blokker brukes, og en av de behandlede blokkene må være omtrent 4 GB i størrelse (minst 2^32 – 200 byte).
Når du behandler inndataene på en gang (uten sekvensiell beregning av hashen etter deler), vises ikke problemet. Som en enklere beskyttelsesmetode foreslås det å begrense den maksimale størrelsen på dataene som er involvert i én iterasjon av hash-beregningen.
Den sårbare koden ble publisert i januar 2011, så det tok mer enn et tiår å finne denne sårbarheten. Det ser ut til å være vanskelig å finne sårbarheter i kryptografiske implementeringer, selv om de spiller en kritisk rolle i den generelle sikkerheten til et system. (Kanskje folk ikke engang ser etter slike sårbarheter, siden verken denne sårbarheten i XKCP eller Apple-sårbarheten nevnt ovenfor er kvalifisert for noen bug-bounty-programmer!)
Sårbarhet skyldes en feil i blokkbehandlingen av inndataene. På grunn av en feil sammenligning av verdiene med typen "int", blir en feil størrelse på de utestående dataene bestemt, noe som fører til at køen skrives ut av den tildelte bufferen.
Spesielt nevnes at ved sammenligning er uttrykket «partialBlock + instance->byteIOIndex«, som med store verdier av komponentdelene førte til heltallsoverløp. Det var også en feil typecast "(unsigned int)(dataByteLen - i)" i koden, noe som forårsaket overløp på systemer med en 64-bit size_t type.
Endelig hvis du er interessert i å vite mer om det, kan du sjekke detaljene i følgende lenke.