Non teorico mumbo jumbo. Qualcuno, mai, in qualche modo, ha reso nota una vulnerabilità sfruttabile reale a causa dell'uso di / dev / urandom? Uno che sarebbe stato mitigato se avessero invece usato / dev / random?
Non teorico mumbo jumbo. Qualcuno, mai, in qualche modo, ha reso nota una vulnerabilità sfruttabile reale a causa dell'uso di / dev / urandom? Uno che sarebbe stato mitigato se avessero invece usato / dev / random?
Sì, ci sono.
Una ricerca rapida mostra CVE-2003-0094 per esempio:
A patch for mcookie in the util-linux package for Mandrake Linux 8.2 and 9.0 uses /dev/urandom instead of /dev/random, which causes mcookie to use an entropy source that is more predictable than expected, which may make it easier for certain types of attacks to succeed.
Durante la sequenza di avvio possono verificarsi problemi nell'utilizzo di / dev / urandom invece di / dev / random . A quel tempo, il sistema potrebbe non avere abbastanza entropia disponibile per fornire numeri casuali sicuri.
Concretamente, questa "entropia" designa il numero di possibili stati interni per il generatore di numeri pseudo-casuali (PRNG):
Quando viene avviata la sequenza di avvio, il sistema inizia da uno stato conosciuto, sempre lo stesso (particolarmente vero per le immagini virtuali) e principalmente lo stesso anche su qualsiasi altro ambiente identico.
Mentre il sistema elabora sempre più "cose" (I / O o qualsiasi altra cosa), anche il numero di stati possibili cresce sempre di più.
Ma durante la sequenza di avvio, vengono elaborate relativamente poche cose e soprattutto queste sono per lo più identiche ogni volta e su ogni ambiente identico.
Il CVE collegato sopra target mcookie , che genera un segreto per l'autenticazione X. Ma la stessa cosa, ad esempio, si applicherebbe anche alla generazione automatica di nuove chiavi SSH al primo avvio dopo l'installazione di un sistema o la distribuzione di una nuova macchina virtuale.
Un attaccante ben fondato potrebbe eseguire la sequenza di avvio iniziale del modello VM decine o centinaia di migliaia di volte e raccogliere le chiavi generate ogni volta. Poiché la combinazione dei modi in cui un sistema appena installato può avviarsi non è infinita, mi aspetto che a un certo punto l'aggressore possa trovare duplicati.
L'attaccante può quindi provare a riutilizzare quelle chiavi contro sistemi identici che stanno ancora utilizzando la chiave generata automaticamente al momento dell'installazione.
Mentre la sequenza di avvio post installazione è la più vulnerabile, la maggior parte (tutti?) i sistemi ora memorizzano un seed in un file da utilizzare in anticipo al prossimo riavvio. Questo file non è niente di speciale, solo una sequenza di byte casuale progettata per violare qualsiasi potenziale determinismo nei primi stati PRNG.
Quindi, oggigiorno, a parte il materiale generato durante la fase di post-installazione, solo il codice eseguito prima che il seme sia stato caricato potrebbe ancora mostrare una vulnerabilità perché utilizza / dev / urandom invece di < em> / dev / random .
Leggi altre domande sui tag random vulnerability