Come può ASLR essere efficace?

Question

Ho sentito la teoria. Indirizzo Spazio La randomizzazione prende le librerie e le carica in posizioni casuali nello spazio degli indirizzi virtuali, in modo che nel caso in cui un hacker trovi un buco nel tuo programma, non ha un indirizzo pre-conosciuto per eseguire un attacco return-to-libc contro, per esempio. Ma dopo averci pensato per qualche secondo, non ha alcun senso come misura difensiva.

Diciamo che il nostro ipotetico TargetLib (libc o qualsiasi altra cosa l'hacker sta cercando) è caricato in un indirizzo casuale invece che in uno deterministico. Ora l'hacker non sa in anticipo dove sono TargetLib e le routine al suo interno, ma nemmeno il codice dell'applicazione. Deve avere una sorta di tabella di ricerca da qualche parte nel binario per trovare le routine all'interno di TargetLib, e questo deve essere in una posizione deterministica. (O in una posizione casuale, indicata da qualcos'altro.È possibile aggiungere quante indicazioni indirette si desidera, ma alla fine si deve iniziare in una posizione nota.)

Ciò significa che invece di puntare il proprio codice di attacco al posizione nota di TargetLib, tutto ciò che l'hacker deve fare è puntare il suo codice di attacco sulla voce della tabella di ricerca dell'applicazione per TargetLib e dereferenziare il puntatore alla routine di destinazione, e l'attacco procede senza impedimenti.

C'è qualcosa nel modo in cui funziona l'ASLR che non capisco? Perché, come descritto, non vedo come sia qualcosa di più di un dosso, fornendo l'immagine della sicurezza ma senza una sostanza reale. Mi sto perdendo qualcosa?

Answer 1

Credo che questo sia efficace perché cambia l'indirizzo di base della libreria condivisa. Ricorda che le funzioni importate da una libreria condivisa vengono applicate all'immagine eseguibile quando viene caricata, e quindi non esiste una tabella di per sé, solo indirizzi specifici che puntano a dati e codice sparsi nel codice del programma.

Solleva la barra per un attacco efficace perché rende un semplice overrun del buffer (dove è possibile impostare l'indirizzo di ritorno nello stack) in uno in cui il sovraccarico deve contenere il codice per determinare la posizione corretta e quindi jmp ad esso . Presumibilmente questo rende solo più difficile.

Praticamente tutte le DLL in Windows sono compilate per un indirizzo di base a cui probabilmente non verranno eseguite e verranno comunque spostate, ma quelle principali di Windows tendono ad avere il loro indirizzo di base ottimizzato in modo che il trasferimento non sia necessario.

Answer 2

Non so se ti faccio domande correttamente ma ti spiegherò quando ASLR è efficace e quando no.

Supponiamo di avere app.exe e TargetLib.dll. app.exe sta utilizzando (collegato a) TargetLib.dll. Per semplificare la spiegazione, supponiamo che lo spazio degli indirizzi virtuali contenga solo questi 2 moduli.

Se entrambi sono abilitati per ALSR, l'indirizzo di base di app.exe è sconosciuto. Può risolvere alcuni indirizzi di chiamata di funzione quando viene caricato, ma un utente malintenzionato non sa né dove si trova la funzione né dove si trovano le variabili risolte. La stessa cosa accade quando viene caricato TargetLib.dll. Anche se app.exe ha una tabella di ricerca, un utente malintenzionato non sa dove si trova la tabella.

Poiché un utente malintenzionato non può stabilire quale sia il contenuto dell'indirizzo specifico, deve attaccare l'applicazione senza utilizzare alcuna informazione di indirizzo fissa. Di solito è più difficile se usa il solito metodo di attacco come overflow dello stack, overflow dell'heap, use-after-free ...

D'altra parte, se app.exe non è ASLR abilitato, è molto più facile per un utente malintenzionato sfruttare l'applicazione. Perché potrebbe esserci una chiamata di funzione a un'interfaccia API interessante a indirizzo specifico nell'app.exe e l'attaccante può usare l'indirizzo come indirizzo di destinazione per saltare. (L'attacco ad un'applicazione di solito inizia dal salto verso un indirizzo arbitrario).

supplementazione: si può già capire, ma voglio chiarire una cosa. Quando un utente malintenzionato sfrutta un'applicazione per vulnerabilità come il danneggiamento della memoria, di solito è obbligato a utilizzare fixed address jump instruction. Non possono usare l'istruzione relative address jump da sfruttare. Questo è il motivo per cui ALSR è davvero efficace per tali exploit.