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:
- Questo è davvero un bug da utilizzare dopo l'uso?
- 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.