Heartbleed - Legge solo i successivi 64k e lancia la minaccia

Il blocco da 64k che viene restituito viene selezionato in modo efficace a caso, il che sembra che renderebbe difficile trovare dati utili. Tuttavia, ci sono due fattori che aumentano significativamente la minaccia:

Innanzitutto, l'attacco non restituirà la memoria che è stata allocata durante l'avvio del programma. Ciò significa che l'area occupata da cose noiose come il codice del programma non verrà mostrata nei risultati di attacco; allo stesso modo, la metà dello spazio degli indirizzi riservato al sistema operativo non verrà restituita.

In secondo luogo, a causa di come viene eseguita l'allocazione della memoria, il blocco a 64k tenderà a provenire dalla memoria utilizzata di recente. Ad esempio, se un server gestisce molti tentativi di accesso, è probabile che la memoria sia stata utilizzata per un accesso recente e potrebbe benissimo contenere una o due coppie di nome utente / password. Un buon tempismo potrebbe farti usare la memoria per impostare la connessione SSL e potresti trovare una chiave privata SSL in questo.

Un terzo punto è che l'attacco può essere eseguito rapidamente e ripetutamente ed è quasi impossibile da rilevare. Una connessione Internet domestica potrebbe essere in grado di colpire un server con decine di migliaia di richieste heartbeat al secondo.

Il bug Heartbleed consente infatti ad altre parti di leggere la memoria al di fuori dello spazio previsto, ma lo fa non consente di leggere la memoria da altri processi . L'indirizzo iniziale non può essere modificato dall'attaccante, dipende in realtà dall'algoritmo di allocazione della memoria che la memoria deve restituire. Molto probabilmente questa è la memoria di una richiesta HTTP recente (per server Web e browser). Per i server Web molto affollati, esiste un'alta probabilità di ottenere dati completamente diversi perché la memoria è stata sovrascritta mentre serviva altri utenti.

Cloudflare ha studiato il possibilità di ottenere una chiave SSL privata dal server Web di nginx, ma è altamente improbabile che comprima la chiave privata. L'argomento principale è che il server web nginx carica la chiave privata molto presto durante l'avvio. Non è allocata / utilizzata molta memoria in quel momento, quindi la chiave privata è archiviata a un indirizzo basso. Quando arrivano nuove richieste, vengono utilizzati indirizzi più distanti, quindi pensano che sia difficile (e probabilmente impossibile) ottenere la chiave. Ecco perché hanno presentato una sfida che chiede ai tester di dimostrare il contrario.

Si noti che non esiste una prova davvero certa che non sia possibile ottenere le chiavi. L'atteggiamento paranoico (e sicuro) è quindi supporre che sia possibile (anche se la probabilità di essere colpiti da un meteorite è più alta). Per dimostrare che non è possibile ottenere le chiavi usando questo singolo bug , si dovrebbe controllare attentamente come funziona l'allocatore di memoria e come altri fattori esterni possono influenzare l'indirizzamento.

I ricercatori sono riusciti a ottenere la chiave privata in "condizioni di laboratorio". Quali erano queste condizioni? Se eseguono un server web personalizzato che utilizza OpenSSL su un dispositivo embedded a bassa memoria, questo potrebbe rendere molto più semplice ottenere la chiave privata, ma non è realistico.

Indipendentemente dal fatto che le chiavi private possano essere trapelate o meno, è stato dimostrato che le richieste e le risposte HTTP recenti possono essere lette dalla memoria. Ciò include le password (vedi Yahoo, conosco qualcuno che ha ottenuto 3k password in breve tempo), documenti aziendali, codice sorgente (comprese le credenziali del database), token di accesso, ID di sessione e altro. Sebbene la chiave privata principale non sia stata rubata, è ancora del tutto possibile che i segreti premaster siano trapelati e ciò consentirebbe a qualcuno che ha annusato la rete di decrittografare i dati crittografati.

Per quanto riguarda il controllo, non può vedere nei log di accesso dei server web che è stato attaccato con questo bug. Puoi solo dire con una cattura di pacchetti.

Poiché gli attacchi sono piuttosto invisibili e il bug consente agli aggressori remoti di raccogliere facilmente dati che normalmente non sono accessibili all'esterno (codice sorgente) o dovrebbero essere crittografati (password), a mio parere Heartbleed è piuttosto severo. Ha ottenuto molta stampa, ma sembra essere giustificato.

C'è stata una risposta qui che è stata cancellata da allora che è stata davvero interessante, almeno nei commenti che ha provocato.

Essenzialmente, il rispondente era (non molto chiaramente) cercando di dire che ogni nuova allocazione di buffer per leggere l'heartbeat da cambia l'indirizzo di partenza, e perché si è in grado di eseguire l'attacco molte volte, si è in grado di estrarre casualmente dati da una particolare area di RAM, colpendo ogni volta un punto diverso.

Mark dice nella sua risposta sopra:

The 64k block that gets returned is selected effectively at random

Inoltre presumibilmente allude a questo meccanismo.