Se sfruttati, questi difetti possono consentire agli aggressori di ottenere l'accesso non autorizzato a informazioni riservate o, in generale, causare problemi
È stata individuata una vulnerabilità (già elencato sotto CVE-2022-37454) en l'implementazione della funzione di hash crittografica SHA-3 (Keccak), offerto nel pacchetto XKCP (eXtended Keccak Code Package).
La vulnerabilità individuata può causare un overflow del buffer durante il trattamento dei dati formati. Il problema è dovuto a un bug nel codice di una specifica implementazione di SHA-3, non a una vulnerabilità nell'algoritmo stesso.
El Paquete XKCP è pubblicizzato come l'implementazione ufficiale di SHA-3, sviluppato con l'aiuto del team di sviluppo Keccak, e utilizzato come base per le funzioni da utilizzare con SHA-3 in vari linguaggi di programmazione (ad esempio il codice XKCP è utilizzato nel modulo hashlib Python, nel pacchetto Ruby digest-sha3 e nelle funzioni PHP hash_*).
Secondo il ricercatore che ha identificato il problema, potrebbe utilizzare la vulnerabilità per violare le proprietà crittografiche della funzione hash e trovare la prima e la seconda preimmagine, oltre a determinare le collisioni.
Il motivo dell'errore di segmentazione è che gli script cercheranno di scrivere più dati in un buffer di quanti ne possano contenere. Tale vulnerabilità è nota come buffer overflow, che OWASP descrive come "probabilmente la forma più nota di vulnerabilità della sicurezza del software".
Una piccola variante del codice causerà un loop infinito: basta sostituire 4294967295 con 4294967296. Notare la somiglianza con CVE-2019-8741, un'altra vulnerabilità che ho riscontrato che ha interessato il firmware di oltre 1.400 miliardi di dispositivi Apple, causando anche un loop infinito.
Anche, viene annunciata la creazione di un exploit prototipo, que consente di ottenere l'esecuzione del codice durante il calcolo dell'hash da un file appositamente progettato. La vulnerabilità può anche essere potenzialmente utilizzata per attaccare gli algoritmi di verifica della firma digitale utilizzando SHA-3 (ad esempio, Ed448). I dettagli sui metodi di attacco dovrebbero essere rilasciati in un secondo momento, dopo la rimozione generale della vulnerabilità.
Questo tipo di comportamento non dovrebbe verificarsi in linguaggi "sicuri" come Python e PHP, poiché controllano che tutte le operazioni di lettura e scrittura rientrino nei limiti del buffer. Tuttavia, il problema è che la vulnerabilità è presente nel sottostante linguaggio C "insicuro"...
Ancora non è chiaro come la vulnerabilità influisca nella pratica sulle applicazioni esistenti, poiché affinché il problema si manifesti nel codice, è necessario utilizzare il calcolo hash ciclico sui blocchi e uno dei blocchi elaborati deve avere una dimensione di circa 4 GB (almeno 2^32 – 200 byte) .
Quando si elaborano i dati di input in una volta (senza il calcolo sequenziale dell'hash per parti), il problema non si verifica. Come metodo di protezione più semplice, si propone di limitare la dimensione massima dei dati coinvolti in un'iterazione del calcolo dell'hash.
Il codice vulnerabile è stato pubblicato nel gennaio 2011, quindi ci sono voluti più di un decennio per trovare questa vulnerabilità. Sembra essere difficile trovare vulnerabilità nelle implementazioni crittografiche, anche se svolgono un ruolo critico nella sicurezza generale di un sistema. (Forse le persone non stanno nemmeno cercando tali vulnerabilità, dal momento che né questa vulnerabilità in XKCP né la vulnerabilità Apple menzionata sopra sono idonee per alcun programma di ricompense di bug!)
Vulnerabilità è dovuto a un errore nell'elaborazione del blocco dei dati di ingresso. A causa di un confronto errato dei valori con il tipo "int", viene determinata una dimensione errata dei dati in sospeso, che provoca la scrittura della coda dal buffer allocato.
In particolare, si ricorda che nel confronto, l'espressione «blocco parziale + istanza->byteIOIndex«, che, con valori elevati delle parti componenti, ha portato all'overflow di interi. Inoltre, c'era un typecast errato "(unsigned int)(dataByteLen - i)" nel codice, causando un overflow sui sistemi con un tipo size_t a 64 bit.
Infine se sei interessato a saperne di più, puoi controllare i dettagli nel file seguente link