Come aggirare ASLR con ROP

Question

Come aggirare ASLR con ROP

Naviga le tue risposte

#1 da (3 voti)

5

Stavo leggendo questo articolo dall'istituto di InfoSec:

link

Ed è stato in grado di seguire fino a quando ha fatto la catena ROP.

Trova che l'offset di printf e execve sia 328160

Quindi trova i seguenti gadget ROP:

0x804886eL: add eax [ebx-0xb8a0008] ; add esp 0x4 ; pop ebx
0x804861fL: call eax ; leave ;;
0x804849cL: pop eax ; pop ebx ; leave ;;

Comprendo che l'idea è di caricare l'indirizzo assoluto di execve in eax e poi chiamare eax, ma dove mi perdo è il modo in cui lo fa.

Il gadget:

0x804886eL: add eax [ebx-0xb8a0008] ; add esp 0x4 ; pop ebx

Aggiunge eax e [ebx - 0xb8a0008] e poi lo memorizza in eax per il prossimo gadget da chiamare.

L'obiettivo ora sembra essere quello di ottenere ebx per contenere l'indirizzo assoluto di printf @ ottenuto, ma invece carica 0x138e9ff4 in ebx, dice il suo perché:

printf @ ha ottenuto + 0xb8a0008 = 0x138e9ff4

Non ho idea di come calcoli il valore 0x138e9ff4, dato che ASLR è abilitato e printf @ got dovrebbe essere diverso ogni volta, e quindi anche il valore caricato in ebx dovrebbe.

Gradirei qualsiasi input che hai

assembly exploit glibc exploit-development

posta alloy 30.07.2017 - 22:47

fonte

1 risposta

Leggi altre domande sui tag assembly exploit glibc exploit-development

Il malware in $ RECYCLE.BIN (file cancellati) è pericoloso? Utilità di più sottochiavi di firma quando siamo limitati a una singola sottochiave di crittografia in GnuPG (PGP)

score 3 · Answer 1

Sono d'accordo che sia spiegato molto male nell'articolo. Mi ci sono volute diverse letture per capire cosa stava succedendo.

La parte chiave è qui:

Our aim now is to build a chained ROP to execute execve(). As we can see, we don’t have a GOT entry for this function and libc is randomized.

So what we will do first is to leak a libc function address for GOT then we will do some trivial calculation to get the exact execve libc address.

Stanno partendo dal presupposto che tu abbia una perdita di informazioni che ti dice dove si trova una singola funzione di libc. In questo caso, stanno usando printf come esempio.

Da lì, l'exploit ha molto più senso:

Il primo passo è che popolano eax con 0x328160 ed ebx con 0x138e9ff4 utilizzando il gadget pop; pop; leave . Quando viene eseguita l'istruzione add , calcola 0x138e9ff4 - 0xb8a0008 = 0x8049fec. Questo è l'indirizzo di printf @ ottenuto nell'esempio. Si noti che questo è l'indirizzo della voce GOT (Global Offsets Table) per printf, non la funzione printf stessa. L'indirizzo di base del GOT non è randomizzato in Linux regolare (potrebbe essere in kernel grsec-hardened, non l'ho esaminato)

L'istruzione ora è essenzialmente: add eax, [0x8049fec] . L'attaccante sa che per la versione di destinazione di libc la distanza tra printf ed execve è 0x328160, quindi quando questa istruzione viene eseguita prende l'indirizzo della funzione printf dal GOT e aggiunge 0x328160 ad esso (da eax, che è stato precaricato dal pop pop leave) che carica l'indirizzo di execve in eax.

Il call eax quindi esegue execve.