CVE-2021-41117

Riepilogo

keypair è un generatore di chiavi RSA PEM scritto in JavaScript. keypair implementa molte primitive crittografiche autonomamente o attingendo da altre librerie quando possibile, tra cui node-forge. È stato scoperto un problema per cui questa libreria generava chiavi RSA identiche usate in SSH. Ciò significherebbe che la libreria genera valori P, Q (e quindi N) identici, il che, in termini pratici, è impossibile con chiavi RSA-2048. La generazione ripetuta di valori identici di solito indica un problema legato a una scarsa generazione di numeri casuali o a una gestione inadeguata dell'output del CSPRNG. Problema 1: Scarsa generazione di numeri casuali (`GHSL-2021-1012`). La libreria non si affida interamente a un CSPRNG fornito dalla piattaforma, ma usa un proprio approccio CMAC basato su contatore. Il punto critico è l'inizializzazione del seed dell'implementazione CMAC con dati "veramente" casuali nella funzione `defaultSeedFile`. Per generare il seed del generatore AES-CMAC, la libreria adotta due approcci diversi a seconda dell'ambiente di esecuzione JavaScript. In un browser, la libreria usa [`window.crypto.getRandomValues()`](https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L971). Tuttavia, in un ambiente di esecuzione NodeJS, l'oggetto `window` non è definito, quindi la libreria ripiega su una soluzione molto meno sicura, che tra l'altro contiene un bug. Sembra che la libreria tenti di usare il CSPRNG di Node quando possibile; sfortunatamente, l'oggetto `crypto` è null perché una variabile è stata dichiarata con lo stesso nome e impostata a `null`. Quindi il percorso CSPRNG di Node non viene mai intrapreso. Tuttavia, quando `window.crypto.getRandomValues()` non è disponibile, viene usato un generatore di numeri casuali Lehmer LCG per inizializzare il contatore CMAC, e l'LCG viene inizializzato con `Math.random`. Sebbene questa sia una pratica inadeguata e probabilmente costituirebbe di per sé un bug di sicurezza, non spiega l'estrema frequenza con cui si verificano chiavi duplicate. Il difetto principale: l'output del Lehmer LCG viene codificato in modo errato. La [riga][https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L1008] specifica con il difetto è: `b.putByte(String.fromCharCode(next & 0xFF))` La [definizione](https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L350-L352) di `putByte` è `util.ByteBuffer.prototype.putByte = function(b) {this.data += String.fromCharCode(b);};`. In forma semplificata, si tratta di `String.fromCharCode(String.fromCharCode(next & 0xFF))`. Il doppio `String.fromCharCode` è quasi certamente non intenzionale ed è la causa di un seed debole. Sfortunatamente, ciò non produce un errore. Piuttosto, fa sì che la maggior parte del buffer contenga zeri. Poiché applichiamo una maschera con 0xFF, possiamo determinare che il 97% dell'output dell'LCG viene convertito in zeri. Gli unici output che producono valori significativi sono quelli da 48 a 57 inclusi. L'impatto è che ogni byte nel seed del RNG ha una probabilità del 97% di essere 0 a causa della conversione errata. Quando non è 0, i byte vanno da 0 a 9. In sintesi, ci sono tre problemi immediati: 1. La libreria ha un percorso di fallback insicuro per i numeri casuali. Idealmente, la libreria dovrebbe richiedere un CSPRNG forte invece di tentare di usare un LCG e `Math.random`. 2. La libreria non usa correttamente un generatore di numeri casuali forte quando viene eseguita in NodeJS, anche se è disponibile un CSPRNG forte. 3. Il percorso di fallback presenta un problema nell'implementazione per cui la maggior parte dei dati del seed sarà di fatto zero. A causa della scarsa generazione di numeri casuali, keypair genera chiavi RSA relativamente facili da indovinare. Ciò potrebbe consentire a un attaccante di decrittare messaggi confidenziali o ottenere accesso autorizzato a un account della vittima.