Ecco lo scenario:
Si arriva a sovrascrivere 4 byte (consecutivi) di un processo remoto Userland in Linux senza Mitigazione degli exploit e senza la possibilità di iniettare alcun Shellcode e si conosce il Process Memory Layout. È sfruttabile?
Nel senso che puoi far sì che il programma agisca in un modo che non dovrebbe, allora sì questo è sfruttabile. esattamente in che misura puoi sfruttare il processo dipende interamente dal processo stesso.
Causare il processo di terminare con un errore (Denial of Service) è facile, basta scrivere 4 byte casuali in una posizione casuale e probabilmente lo farai.
Una sovrascrittura di 4 byte consente di soppiantare un valore di indirizzo a 32 bit. La prima cosa che viene in mente è sovvertire il flusso del programma, a return , a call oa jump .
Se riesci a trovare un pezzo di codice che ti fa qualcosa di utile, in genere osservando le librerie che sono state caricate, puoi saltare a quello. Potresti anche essere in grado di effettuare una chiamata di sistema se riesci a trovare una situazione in cui gli argomenti corretti sono caricati nello stack prima di un'istruzione di flusso del programma.
Potresti sovrascrivere il valore di un puntatore sulla pila per puntare a qualcos'altro, questo potrebbe facilmente portare a divulgazione di informazioni . Come alterare il puntatore che punta alla stringa del nome utente in modo che punti ad una chiave segreta, o un hash della password, e quindi interagendo con il programma in modo tale che di solito echi la stringa del nome utente .
È possibile modificare una voce in Tabella offset globale per soppiantare una chiamata di funzione con un'altra chiamata di funzione a livello globale attraverso il processo. Ciò ti consentirebbe, ad esempio, di rimuovere una funzione wrapper facendo in modo che tutte le chiamate al wrapper chiamino effettivamente la funzione interna, rimuovendo potenzialmente una funzionalità di sicurezza, come un controllo dei parametri, che potresti successivamente sfruttare.
Potrei andare avanti, ma l'idea è o;
Solo perché non si può iniettare direttamente shellcode non significa che non si possa iniettarlo affatto. Forse c'è un modo per caricare un file che verrà aperto dall'applicazione. Se l'applicazione è in ascolto sulla rete, puoi iniziare a comunicare con essa; anche se abbandona rapidamente la richiesta perché non è possibile autenticarsi, rimane comunque il pacchetto in memoria. L'iniezione dello shellcode può (e spesso deve) essere eseguita attraverso mezzi legittimi, con la vulnerabilità che ti permette solo di saltarci sopra.
Se l'applicazione esegue una fase di autenticazione in qualsiasi momento, ignorala o annullala.
4 byte ti consente di cambiare un indirizzo. Ad esempio, è possibile sostituire una chiamata di funzione con un'altra. Potrebbe esserci una stringa interessante per chiamare system su già in memoria, o potresti essere in grado di fornirne una. Se l'applicazione apre un socket, ordina di saltare nel codice di apertura del socket (ad esempio, in una chiamata bind ) mentre i registri puntano a una struttura non intenzionale che fa sì che ascolti una connessione proveniente da te. Cambiare AF_UNIX in AF_INET in una chiamata socket (modifica a byte singolo) potrebbe essere tutto ciò che serve se sei fortunato.