È possibile utilizzare Heartbleed per ottenere memoria da altri processi?

Esiste un'analisi ben scritta al link completa di esempi di codice .

L'autore, Sean Cassidy , osserva che (sottolinea il mio):

What if the requester didn't actually supply payload bytes, like she said she did? What if pl really is only one byte? Then the read from memcpy is going to read whatever memory was near the SSLv3 record.

And apparently, there's a lot of stuff nearby.

To be honest, I am a little surprised at the claims of the people who found the Heartbleed vulnerability. When I heard about it, I figured that 64KB wasn't enough to look for things like secret keys. The heap, on x86 at least, grows up, so I figured that pl would simply read into newly allocated memory, such as bp. Keys and the like would be allocated earlier, so you wouldn't be able to read them. Of course, with modern malloc implementations, this isn't always true.

And further, you won't be able to read the memory of any other process, so those "business critical documents" would need to be in memory of the process, less than 64KB, and be nearby pl.

Un punto di vista alternativo da Erik Cabetas di Includi sicurezza , commentando Reddit:

Was having some discussions w/ my friend about this bug. He thinks it's exploitable by using a variety of specifically sized allocations across the heap to read the 64k chunks all around the heap fragments, not in a linear type of fashion that Sean in OP's link is implying. After thinking about the way ptmalloc/linux allocates, I think this is possible for sure. The .fi guys from codenomicron are sharp dudes, I bet they were able to get the allocations just right in a lab environment.

Modifica: Sean ha aggiornato :

And apparently, there's a lot of stuff nearby.

There are two ways memory is dynamically allocated with malloc (at least on Linux): using sbrk and using mmap. If the memory is allocated with sbrk, then it uses the old heap-grows-up rules and limits what can be found with this, although multiple requests (especially simultaneously) could still find some fun stuff.

However, if mmap is used, all bets are off. Any memory not in use could be allocated for mmap. This is what the most of the attacks against Heartbleed will target.

And the best part: the bigger your requested block, the more likley it is to be served by mmap rather than sbrk.

Per aggiungere la risposta di @ scuzzy-delta: per definizione, i sovraccarichi del buffer nel codice applicativo riguardano solo il codice applicativo. Il sistema operativo mantiene l'isolamento tra i vari processi e non consente a un processo di accedere allo spazio di memoria di un altro processo.

Se il sovraccarico del buffer è di persuasione "di scrittura" (l'attaccante forza il bersaglio a scrivere byte oltre la fine di un buffer), allora questo può essere trasformato in un dirottamento l'attaccante prende il controllo dell'applicazione di destinazione e fa in modo che esegua le sue offerte. I privilegi a livello di applicazione sono già sufficienti per mettere in atto un notevole danno, inclusa la lettura (ad esempio) di tutto il profilo del browser, l'acquisizione del contenuto dello schermo e delle voci della tastiera e così via (quando si verifica su un lato "client", ad esempio in un browser ). Tuttavia, in questo caso, la vulnerabilità "heartbleed" è un overrun "letto", che rivela i dati ma non influisce sul sistema di destinazione. Questo preclude il rischio immediato di dirottamento nemico e le sue terribili conseguenze.

Tuttavia ...

Ottenere i segreti dalla memoria applicativa del processo di destinazione può essere sfruttato in un attacco più esteso. Ad esempio, se il target è un server Web, il problema heartbleed può rivelare (con la giusta quantità di fortuna) i nomi e le password di alcuni altri utenti, che possono quindi essere utilizzati per accedere come questi utenti. Questo può essere problematico.

Per un browser Web, ad esempio sul lato client, si può notare che i alcuni browser hanno l'abitudine di avviare istanze di processo distinte, per evitare problemi di frammentazione della memoria in sessioni di lunga durata, e anche per evitare di perdere l'intero browser quando si verifica un arresto anomalo del plug-in di Flash. Tuttavia, non tutti i browser lo fanno, e anche per quelli che lo fanno, non lo fanno sistematicamente. Seguono l'euristica per raggruppare le schede "insieme" in un unico processo.

Un punto in più è che questi processi spesso usano alcuni memoria condivisa per scambiare alcune informazioni necessarie, in particolare cache di password e cookie e sessioni SSL. Precisamente il tipo di dati succosi che l'aggressore vorrebbe ottenere.

Dal lato positivo, attaccare il client richiede che il server che il client comunica per eseguire l'attacco. Non può essere avviato dall'attaccante; deve aspettare che i client si connettano.