Sfruttabilità delle vulnerabilità use-after-free

Question

Sfruttabilità delle vulnerabilità use-after-free

#1 da (2 voti)

8

Gli errori use-after-free sono una particolare classe di bug di sicurezza della memoria. Quanto spesso sono sfruttabili, in pratica? Quando trovi un bug "use-after-free" in un programma, è spesso sfruttabile, raramente sfruttabile o varia in base ad altri fattori che trascuro?

Sono particolarmente interessato a quanto spesso gli errori use-after-free nei programmi C sono sfruttabili (in particolare, C, piuttosto che C ++). Con quale frequenza vengono sfruttati gli errori use-after-free nei programmi C? Se scopro un bug "use-after-free" in un programma C che sto testando, cosa dovrei stimare come probabilità che sia sfruttabile? 90%? 50%? 10%? Quando si verificano errori di triaging (ad esempio, arresti di fuzzer, avvisi di Valgrind, avvisi da strumenti di analisi statici), quanto dovrei dare la priorità alla risoluzione dei bug di use-after-free, rispetto ad altri tipi di bug di sicurezza della memoria?

Ricerche che ho fatto. Ho fatto qualche ricerca. Sembra che i bug use-after-free nei programmi C ++ siano spesso sfruttabili (perché il layout di memoria di un oggetto C ++ contiene sempre un puntatore a un vtable e sovrascrive questo conduce facilmente al codice di iniezione). Ok bene. Ora che dire dei programmi C?

Posso anche vedere come gli errori use-after-free possono essere sfruttati in alcuni casi speciali. Ad esempio, i bug di use-after-free nei browser o altri programmi con scripting controllabile dall'utente sembrano spesso è sfruttabile , a causa della facilità con cui si esegue l'irrorazione dell'heap e la grande quantità di controllo sui contenuti degli oggetti archiviati in memoria . E, sì, ho visto alcuni metodi sofisticati di sfruttare i bachi use-after-free in alcuni casi speciali (ad esempio, usarli per la divulgazione di informazioni, che consente di derandomizzare ASLR, dopo di che ....), ma quelli sembrano piuttosto specifico dell'applicazione e come potrebbe aver bisogno di essere fortunato per l'attacco a lavorare e anche allora ci vorrebbe un sacco di lavoro per costruire l'exploit. Ma sono interessante sapere come appare il "caso tipico", piuttosto che i casi speciali in cui l'autore dell'attacco è fortunato.

c appsec fuzzing

posta D.W. 21.03.2014 - 21:24

fonte

1 risposta

Leggi altre domande sui tag c appsec fuzzing

Richiede 2 chiavi per accedere a un contenuto DEVO DAVVERO cambiare la mia password LastPass?

score 2 · Answer 1

Gli attacchi use-after-free richiedono che l'attacker sia in grado di allocare memoria attendibilmente in heap.

Supponiamo di avere un oggetto che richiede 16 byte e che viene assegnato in memoria a 0xb00000004 (numeri completamente composti qui). Elimina questo oggetto e la memoria viene restituita all'heap. Ora richiedo un'altra allocazione dell'heap per 16 byte (una stringa per esempio) e l'heap lo alloca su 0xb0000004. Ora un puntatore che fa riferimento al vecchio oggetto chiama invece il nuovo oggetto, senza nemmeno rendersene conto.

Come hai già detto, questo è popolare con i linguaggi di scripting per un motivo. Questo perché i linguaggi di scripting possono attendibilmente allocare memoria sullo heap.

Quindi, per sapere se sarai vulnerabile, devi valutare quanto sarebbe difficile per un utente malintenzionato allocare memoria e se tale aggressore potrebbe allocarlo in modo affidabile.

In un programma in C, il rischio potenziale appare è minore in quanto tali puntatori o riferimenti saranno sui tipi di dati di base, non sugli oggetti. Come può un utente malintenzionato eseguire codice arbitrario quando il programma lo tratta invece come dati? In tal caso è necessario analizzare se i dati sono affidabili.

Ad esempio, supponiamo che il tuo programma memorizzi una stringa " link program.zip" e tu disponga del codice per scaricare, estrarre e eseguirlo. Se un utente malintenzionato è in qualche modo in grado di sovrascrivere quella stringa in link ", allora il tuo programma potrebbe involontariamente installare una shell.