Aiuto nella comprensione del crash di un'applicazione - sfruttabile?

11

Essendo nuovo alla ricerca di vulnerabilità nelle applicazioni native (al contrario delle app web), ho difficoltà a capire un crash nel browser di Debian, Epiphany (versione 2.30.6), e determinare se è sfruttabile.

Ho scoperto che il seguente codice HTML + CSS causa un arresto anomalo in Epiphany, quando si verifica un reindirizzamento a un'altra pagina:

<!DOCTYPE html>
<html>
<head>
<style type="text/css">
::-webkit-scrollbar-thumb {
   height:0;
}
::-webkit-scrollbar {
   overflow:visible;
}
</style>
<meta http-equiv="Refresh" content="1; http://www.example.com/" />
</head>
<body></body>
</html>

Finora, ho cercato di informarlo e di determinarne la sfruttabilità utilizzando GDB e Valgrind .

GDB, la maggior parte delle volte, segnala un errore di segmentazione o un indirizzo che cambia ogni volta che lo eseguo. Ho anche visto che riporta SIGILL invece di SIGSEGV, ma è raro. Debugando ulteriormente, ho scoperto che questo è causato da un'istruzione CALL [edx + 0x228] . Il valore del registro edx nel momento in cui questa istruzione viene eseguita cambia leggermente ad ogni esecuzione, ma, secondo la mappa della memoria, è sempre all'interno dell'heap.

Valgrind riporta una lettura non valida della dimensione 4 , [...] 3 byte dopo un blocco di dimensione 61 free'd , appena prima di un Jump all'indirizzo non valido indicato alla riga successiva e, infine, l'errore di segmentazione.

Per me, sembra un bug utilizzabile dopo l'uso gratuito. Mi piacerebbe che qualcuno confermasse che ho ragione.

Supponendo che questo sia, in effetti, un use-after-free, so che il bug potrebbe essere sfruttabile. Tuttavia, non sono mai riuscito a sovrascrivere la memoria all'indirizzo risultante dall'espressione edx + 0x228 e quindi non riesco a controllare il puntatore dell'istruzione.

Credo che la ragione di ciò sia perché l'oggetto viene liberato subito dopo l'avvio del reindirizzamento della pagina, quindi non posso sovrascrivere lo spazio nella memoria che stava occupando con Javascript che viene eseguito quando la pagina viene caricata. Ho provato ad aggiungere un heap spray a window.onunload , tuttavia, l'aggiunta di questo metodo (con qualsiasi tipo di codice all'interno) impedisce effettivamente che si verifichi l'arresto anomalo.

Quindi, in sostanza, le mie domande sono:

  1. Questo è davvero un bug da utilizzare dopo l'uso?
  2. Se lo è, come posso determinare quando l'oggetto viene liberato e quindi cercare di capire se è possibile sovrascrivere la sua posizione in memoria dopo che è stato liberato?

Qualsiasi suggerimento su come determinare se l'esecuzione del codice è possibile con questo bug e su come potrebbe accadere è anch'esso benvenuto.

Grazie.

    
posta mds 06.05.2013 - 07:34
fonte

1 risposta

1

Suppongo che la domanda abbia due parti: "È sfruttabile? Come posso confermarlo?"

Probabilmente lo è. Probabilmente sei sulla strada giusta con lo spray heap. Hai provato a disabilitare ASLR? Ciò aiuterà a chiarire le cose.

Ecco alcuni commenti di un'altra persona:

This bug is not replicable in newer versions. But he could probably perform a heap spray. He is reporting that gdb is reporting a different address every time this is probably* due to ASLR he should turn that off and back on to make sure. He can step through the program by setting some very breakpoints with gdb and determining the context of the crash.

But idk why he isn't trying out the latest version instead of the oldstable release. But I have mad respect for his/her vigor.

    
risposta data 25.07.2013 - 16:25
fonte

Leggi altre domande sui tag