Spesso viene mostrato che è possibile bypassare i dati non eseguibili tramite gli attacchi return-to-libc. È evidente su /bin/sh ma è anche possibile richiamare una shell remota?
Le parti universali di un exploit sono spesso chiamate "shell code" perché di solito fanno esattamente questo: avviare un processo shell e connettere stdin / stdout a un socket di rete.
Questo paper potrebbe essere interessante:
To demonstrate, we perform an over the network brute force return-to-libc attack against a pre-forking concurrent server to gain remote access to a shell.
Certo che è possibile! Che dire di una chiamata a system() ? Lo stack stesso potrebbe non essere eseguibile ma contiene ancora gli argomenti e quindi tutto può essere fatto purché il processo sfruttato venga eseguito con i privilegi necessari.
Penso che, se ho ragione, mi stai chiedendo:
"Qual è la differenza tra un ritorno all'attacco libc vs un overflow del buffer standard ed è ancora possibile un exploit che coinvolge il richiamo di una shell remota?"
La differenza è sottile. Per prima cosa diamo un'occhiata allo stack. Avid adorerà questo pezzo di codice:
int insecure_function(char* source)
{
char buffer[200];
memcpy(buffer, source, strlen(source));
Che è chiaramente vulnerabile a un overflow del buffer. Lo stack per questa funzione dovrebbe apparire così:
Low Address High Address
char buffer --------------------------------- | ret address | char* source
some data 200 sizeof(char)'s long | 0x134543344 | 0x4374234294
Ora, un overflow del buffer tradizionale ti permette di fare questo:
Low Address High Address
char buffer --------------------------------- | ret address | char* source
Shell code here ---------- then some padding --- 0x999999999 | 0x4374234294
/\ |
|| |
--------- < the address points to here < -------------
Questo è un esempio molto semplice: sovrascrivi l'indirizzo di ritorno in modo che punti al tuo stack. In pratica è abbastanza difficile, quindi alla fine usi un slitta NOP che equivale a "obiettivo nel posto giusto ".
Ovviamente, tutto questo viene sconfitto se quell'area dello stack non è eseguibile perché il processore non eseguirà quelle istruzioni. Eccellente!
Beh, non proprio. Non possiamo ottenere il nostro codice shell in memoria da eseguire, ma fortunatamente ci sono molte librerie in codice che faranno praticamente qualsiasi chiamata di sistema. Tecnicamente, potremmo scegliere qualsiasi funzione che ci è piaciuta, completamente, ma la scelta più ovvia è libc poiché fornisce tutti i tipi di funzioni. Come aprire conchiglie. Quindi in questo caso, ciò che facciamo è fornire il nostro stack frame e restituire l'indirizzo a quella funzione:
Low Address High Address
char buffer --------------------------------- | ret address | char* source
Arguments - libc uses these! | 0x011010101 | 0x4374234294
|
< off to libc we go ----------------------
Quando arriviamo a libc, il frame dello stack è impostato con gli argomenti di cui ha bisogno la funzione, quindi possiamo fare qualsiasi cosa che la funzione che abbiamo scelto possa fare, ad es. avvia un'istanza di /bin/sh con il suo IO reindirizzato ovunque ci piaccia.
Questo è chiaramente abbastanza difficile e dipende da molte cose. Quanto è grande il buffer? Viene manipolato overflow del buffer post (sovrascrivendo i tuoi argomenti)? Ti interessa il processo di destinazione (quello il cui stack hai appena scalfito) rimanendo attivo, o no? Lotto di problemi praticamente, ma teoricamente può essere fatto.
Leggi altre domande sui tag operating-systems exploit buffer-overflow