Si s'exploten, aquestes falles poden permetre als atacants obtenir accés no autoritzat a informació confidencial o, en general, causar problemes
S'ha identificat una vulnerabilitat (ja catalogada sota CVE-2022-37454) en la implementació de la funció hash criptogràfica SHA-3 (Keccak), oferta al paquet XKCP (eXtended Keccak Code Package).
La vulnerabilitat identificada pot provocar un desbordament del memòria intermèdia durant el processament dades formades. El problema és degut a un error en el codi d'una implementació específica de SHA-3, no a una vulnerabilitat a l'algorisme en si.
El paquete XKCP es promociona com la implementació oficial de SHA-3, desenvolupat amb l'ajuda de l'equip de desenvolupament de Keccak, i s'utilitza com a base per a funcions per treballar amb SHA-3 en diversos llenguatges de programació (per exemple, el XKCP El codi s'usa al mòdul Python hashlib, el paquet Ruby digest-sha3 i les funcions PHP hash_*).
Segons l'investigador que va identificar el problema, va poder fer servir la vulnerabilitat per violar les propietats criptogràfiques de la funció hash i trobar la primera i segona preimatges, així com determinar col·lisions.
El motiu de la falla de segmentació és que els scripts intentaran escriure més dades en un memòria intermèdia de les que pot contenir. Aquesta vulnerabilitat es coneix com a desbordament de memòria intermèdia, que OWASP descriu com “probablement la forma més coneguda de vulnerabilitat de seguretat de programari”.
Una petita variant del codi causarà un bucle infinit: simplement reemplaça 4294967295 amb 4294967296. Tingueu en compte la similitud amb CVE-2019-8741 , una altra vulnerabilitat que vaig trobar que va afectar el firmware de més de 1.400 milions de dispositius Apple, que també infinit.
A més, s'anuncia la creació d'un exploit prototip, que permet aconseguir l'execució de codi en calcular el hash d'un fitxer especialment dissenyat. Potencialment, la vulnerabilitat també es pot fer servir per atacar algorismes de verificació de signatures digitals usant SHA-3 (per exemple, Ed448). Està previst que els detalls dels mètodes d'atac es publiquin més endavant després de l'eliminació generalitzada de la vulnerabilitat.
Se suposa que aquest tipus de comportament no ha de passar en llenguatges «segurs» com Python i PHP, ja que verifiquen que totes les operacions de lectura i escriptura estiguin dins dels límits del memòria intermèdia. No obstant això, el problema és que la vulnerabilitat és present en el llenguatge C «insegur» subjacent…
encara no és clar com afecta la vulnerabilitat a les aplicacions existents a la pràctica, ja que perquè el problema es manifesti en el codi, cal utilitzar el càlcul de hash cíclic en blocs, i un dels blocs processats ha de tenir una mida d'aproximadament 4 GB (almenys 2 ^ 32 – 200 bytes) .
Quan processeu les dades d'entrada alhora (sense càlcul seqüencial del hash per parts), el problema no apareix. Com a mètode de protecció més simple, es proposa limitar la mida màxima de les dades involucrades en una iteració del càlcul hash.
El codi vulnerable es va publicar el gener del 2011, per la qual cosa es va trigar més d'una dècada a trobar aquesta vulnerabilitat. Sembla difícil trobar vulnerabilitats en les implementacions criptogràfiques, tot i que juguen un paper fonamental en la seguretat general d'un sistema. (Potser la gent ni tan sols està buscant aquestes vulnerabilitats, ja que ni aquesta vulnerabilitat a XKCP ni la vulnerabilitat d'Apple esmentada anteriorment són elegibles per a cap programa de recompenses per errors!)
la vulnerabilitat es deu a un error en el processament de blocs de les dades dentrada. A causa d'una comparació incorrecta dels valors amb el tipus int, es determina una mida incorrecta de les dades pendents, cosa que fa que la cua s'escrigui fora del memòria intermèdia assignada.
En particular, s'esmenta que en comparar, es va utilitzar l'expressió «parcialBlock + instància->byteIOIndex«que, amb valors grans de les parts components, va conduir a un desbordament de sencers. A més, hi va haver un encasellat incorrecte «(int sense signar)(dataByteLen – i)» al codi, cosa que va provocar un desbordament en els sistemes amb un tipus size_t de 64 bits.
Finalment si estàs interessat en poder conèixer més a l'respecte, Pots consultar els detalls al següent enllaç.