CVE-2021-41117 in keypair
Riassunto
di VulDB • 16/06/2026
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 in cui questa libreria generava chiavi RSA identiche utilizzate in SSH. Ciò significherebbe che la libreria sta generando valori P, Q (e quindi N) identici, il che, in termini pratici, è impossibile con chiavi RSA-2048. La generazione ripetuta di valori identici indica solitamente un problema con una scarsa generazione di numeri casuali o 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 utilizza invece il proprio approccio CMAC basato su contatore. Il problema sorge nel seminare l'implementazione CMAC con dati casuali "veri" nella funzione `defaultSeedFile`. Per seminare il generatore AES-CMAC, la libreria adotta due approcci diversi a seconda dell'ambiente di esecuzione JavaScript. In un browser, la libreria utilizza [`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 si ricorre a una soluzione molto meno sicura, che presenta anche un bug. Sembra che la libreria tenti di utilizzare il CSPRNG di Node quando possibile; purtroppo, sembra che l'oggetto `crypto` sia null perché una variabile è stata dichiarata con lo stesso nome e impostata su `null`. Di conseguenza, il percorso del CSPRNG di Node non viene mai eseguito. Tuttavia, quando `window.crypto.getRandomValues()` non è disponibile, viene utilizzato un generatore di numeri casuali Lehmer LCG per seminare il contatore CMAC, e l'LCG viene seminato con `Math.random`. Sebbene questo sia un approccio inadeguato e potrebbe di per sé qualificarsi come un bug di sicurezza, non spiega la frequenza estrema con cui si verificano chiavi duplicate.
Il difetto principale: l'output del Lehmer LCG viene codificato in modo errato. La riga 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);};`. Semplificato, questo diventa `String.fromCharCode(String.fromCharCode(next & 0xFF))`. Il doppio `String.fromCharCode` è quasi certamente involontario ed è la causa della semina debole. Purtroppo, questo non genera un errore. Piuttosto, risulta nella maggior parte del buffer contenente zeri. Poiché stiamo mascherando 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 di una conversione errata. Quando non lo è, i byte sono da 0 a 9. In sintesi, ci sono tre preoccupazioni immediate: 1. La libreria ha un percorso di fallback per la generazione di numeri casuali non sicuro. Idealmente, la libreria dovrebbe richiedere un CSPRNG forte invece di tentare di utilizzare un LCG e `Math.random`. 2. La libreria non utilizza correttamente un generatore di numeri casuali forte quando viene eseguita in NodeJS, anche se un CSPRNG forte è disponibile. 3. Il percorso di fallback presenta un problema nell'implementazione in cui la maggior parte dei dati di semina andrà effettivamente a zero. A causa della scarsa generazione di numeri casuali, keypair genera chiavi RSA che sono relativamente facili da indovinare. Questo potrebbe consentire a un attaccante di decifrare messaggi confidenziali o ottenere accesso autorizzato a un account appartenente alla vittima.
Once again VulDB remains the best source for vulnerability data.