Perchè LibreSSL PRNG non è sicuro su Linux?

8

Dall'articolo Il PRNG di LibreSSL non è sicuro su Linux .

The first version of LibreSSL portable, 2.0.0, was released a few days ago (followed soon after by 2.0.1). Despite the 2.0.x version numbers, these are only preview releases and shouldn't be used in production yet, but have been released to solicit testing and feedback. After testing and examining the codebase, my feedback is that the LibreSSL PRNG is not robust on Linux and is less safe than the OpenSSL PRNG that it replaced.

Consider a test program, fork_rand. When linked with OpenSSL, two different calls to RAND_bytes return different data, as expected:

$ cc -o fork_rand fork_rand.c -lcrypto $ ./fork_rand Grandparent (PID = 2735) random bytes = f05a5e107f5ec880adaeead26cfff164e778bab8e5a44bdf521e1445a5758595 Grandchild (PID = 2735) random bytes = 03688e9834f1c020765c8c5ed2e7a50cdd324648ca36652523d1d71ec06199de

When the same program is linked with LibreSSL, two different calls to RAND_bytes return the same data, which is a catastrophic failure of the PRNG:

$ cc -o fork_rand fork_rand.c libressl-2.0.1/crypto/.libs/libcrypto.a -lrt $ ./fork_rand Grandparent (PID = 2728) random bytes = f5093dc49bc9527d6d8c3864be364368780ae1ed190ca0798bf2d39ced29b88c Grandchild (PID = 2728) random bytes = f5093dc49bc9527d6d8c3864be364368780ae1ed190ca0798bf2d39ced29b88c

E:

Unfortunately, when I suggested the second change on Hacker News, a LibreSSL developer replied:

The presence or need for a [RAND_poll] function should be considered a serious design flaw.

Domanda: questo bug è un difetto di progettazione in Linux o si trattava di un errore fatto dagli sviluppatori di LibreSSL?

    
posta evachristine 16.08.2014 - 11:56
fonte

2 risposte

3

Differenze filosofiche. LibreSSL è progettato con la filosofia che una libreria SSL dovrebbe essere una libreria SSL, e niente di più. Ciò significa che non tenta di implementare la metà di libc, o di fornire altre funzionalità a livello di sistema operativo, e non dovrebbe compensare difetti nel sistema operativo - il sistema operativo dovrebbe invece essere riparato. Un pool di entropia di alta qualità è una di quelle strutture che il sistema operativo dovrebbe fornire.

Detto questo, descrivere RAND_bytes come "non sicuro" sta sopravvalutando le cose. È solo pericoloso sotto Linux in condizioni molto limitate:

  1. Il programma usa il modello fork / exec vecchio stile del threading, piuttosto che il modello pthreads più recente.
  2. Il programma deve avere una struttura in cui un processo grandparent genera un processo genitore ed esce, quindi il processo genitore avvia un processo figlio che, casualmente, ottiene lo stesso PID del nonno. Questa è, per usare un eufemismo, una struttura del programma molto insolita.
  3. I processi dei nonni e dei nipoti utilizzano entrambi il PRNG di LibreSSL, mentre il processo tra loro non lo fa. Questa è ancora una struttura di programma molto insolita, in quanto un programma tipico eseguirà operazioni SSL esclusivamente nei nonni (processo di gestione delle connessioni con un gruppo di thread di lavoro) o nei nipoti (gestore dei processi con un gruppo di thread di gestione delle connessioni) .
risposta data 16.08.2014 - 22:19
fonte
0

La risposta è un po 'torbida, da qualche parte tra i due.

Linux ha storicamente esposto il generatore di numeri casuali del kernel come / dev / random e / dev / urandom mentre BSD lo espone con il syscall di getentropy. Risulta che vi sono alcuni vantaggi nell'approccio BSD e, a causa della pressione di LibreSSL, Linux implementerà un syscall simile. maggiori informazioni

LibreSSL si rivolge principalmente a BSD, quindi favoriscono l'approccio syscall. Un altro principio dello sviluppo di LibreSSL è che NON prenderanno troppi problemi per la portabilità o la retrocompatibilità. Presumo che la tua versione di Linux non abbia questo syscall, e mi aspetto che LibreSSL non faccia grandi sforzi per supportare la tua versione di Linux.

    
risposta data 16.08.2014 - 19:51
fonte

Leggi altre domande sui tag