Come funziona il "leaking pointers" per bypassare DEP / ASLR

"Leaky Pointers" o più comunemente noto come "Dangling Pointers" è utile per creare una catena di attacco per bypassare un sistema di sicurezza stratificato.

L'idea alla base di DEP è che si stanno creando regioni di memoria non eseguibili, in modo che lo shellcode in quest'area non possa essere eseguito. DEP da solo è davvero facile da bypassare, puoi semplicemente ret-to-lib e chiamare qualsiasi funzione che desideri, system() è un preferito.

Tuttavia, in Windows, le ASLR librerie abilitate avranno uno spazio di memoria randomizzato, quindi l'attaccante non conoscerà il indirizzo di memoria della funzione system() , e lì per non può chiamarlo. L'idea alla base dell'ASLR è che non importa se puoi controllare l'EIP se non sai dove andare.

Essere in grado di leggere la posizione di una regione di memoria randomizzata mina la protezione dell'ASLR, perché ora si ha una posizione di salto affidabile. Questo può essere realizzato attraverso un'ampia varietà di metodi. L'utilizzo di un buffer overflow per sovrascrivere semplicemente il terminatore null e read oltre la fine di un array è stato utilizzato in pwn2own contro IE. Ma la tecnica più comune è usare un Dangling Pointer che può essere usato per leggere / scrivere o persino eseguire una posizione di memoria valida nonostante ASLR.

Anche con ASLR, non tutte le posizioni di memoria sono randomizzate. Infatti il binario eseguibile ha un layout prevedibile, quindi puoi usare l'eseguibile contro se stesso in una catena ROP . Tuttavia a volte è difficile trovare utili gadget ROP, soprattutto se il binario di destinazione è molto piccolo. Se non si è in grado di creare una catena ROP utile, una vulnerabilità di divulgazione della memoria, come un puntatore pendente, è un ottimo metodo di attacco. È importante notare che ASLR randomizza solo la posizione della pagina (i primi pochi byte dell'indirizzo di memoria), se è possibile popolare una regione all'interno di questa pagina con il proprio shellcode allora è possibile che sia possibile eseguire con precisione lo shellcode usando la memoria trapelata indirizzo come base e quindi si spera che il tuo shellcode sia in qualche modo inoffensivo rispetto a questa posizione casuale.

L'utilizzo di catene di vulnerabilità di manipolazione della memoria è insolitamente possibile solo all'interno di un ambiente di scripting, come JavaScript.

ASLR implica la randomizzazione della posizione degli oggetti nella memoria. Ad esempio, l'heap potrebbe essere spostato su un offset casuale in memoria.

Se in qualche modo riesci a imparare l'indirizzo di un oggetto nell'heap, hai acquisito molte informazioni sulla posizione dell'heap in memoria. Questo potrebbe essere sufficiente per consentire di prevedere la posizione di altri oggetti nell'heap. A quel punto, la randomizzazione di ASLR diventa inutile. Pertanto, le vulnerabilità di divulgazione di informazioni che rivelano il valore di un puntatore (il suo indirizzo) possono potenzialmente essere utilizzate per sovvertire l'ASLR.

Come può l'indirizzo di un puntatore perdere? Un modo è attraverso una vulnerabilità di stringa di formato. Supponiamo che tu faccia qualcosa del genere:

printf(msg);

dove msg è un messaggio controllato da un utente malintenzionato e in cui l'autore dell'attacco può leggere lo stdout. Quindi l'utente malintenzionato può specificare che il messaggio deve essere la stringa "%d" e questo rivelerà il valore di alcuni dati casuali nello stack, che potrebbe essere un puntatore valido. (Perché? Perche printf() pensa di aver passato un altro argomento e va in cerca sullo stack per trovare e stampare il valore di tale argomento addizionale.) Non ha idea che in realtà non hai passato un altro argomento e in realtà sta navigando attraverso la memoria non correlata .)

Ci sono altri modi in cui questo tipo di informazione può essere trapelato, ma quando è possibile, puoi spesso bypassare ASLR. Una volta superato l'ASLR, è possibile utilizzare tecniche standard per sfruttare una vulnerabilità di sovraccarico del buffer. Quindi, questo tipo di vulnerabilità di divulgazione di informazioni non è una buona cosa da avere nella tua applicazione.