Come funziona l'esecuzione di codice arbitrario?

Ogni vulnerabilità ha una causa specifica, che a sua volta porta a sfruttare la vulnerabilità. È difficile capire come si possa sfruttare qualcosa di astratto e ottenere risultati astratti, ma è molto più facile da capire se illustrato con esempi. Il più semplice sarebbe il classico overflow del buffer basato su stack:

void f(const char *str) {
  char buf[10];
  strcpy(buf, str);
}

Questo è un esempio primitivo che dovrebbe essere sufficiente per dimostrare il problema. Supponiamo che l'argomento str punti a una stringa con terminazione NULL più lunga dei 10 caratteri allocati per la variabile in fase di copia. Cosa accadrà? strcpy() copierà ciecamente i dati oltre la fine del buffer, sovrascrivendo quello che c'era. Ma cosa esattamente è lì?

Su x86, ad esempio, la variabile buf verrebbe allocata nello stack. Lo stack viene anche utilizzato per salvare l'indirizzo di ritorno quando viene eseguita un'istruzione CALL . Quindi il layout dello stack (semplificato) sarà simile a questo (gli indirizzi aumentano dall'alto al basso):

...
buf[0..3]
buf[4..7]
buf[8..9]
return address
...

Quindi, fornendo una stringa troppo lunga tramite l'argomento str , saremmo in grado di sovrascrivere l'indirizzo di ritorno da f() . Se l'attaccante è in grado di controllare la stringa, allora può controllare dove andrà il flusso di controllo dopo il ritorno di f() . Ciò può verificarsi quando si analizza un file appositamente predisposto, ad esempio.

La prossima cosa sarebbe dirigere il controllo su un'istruzione JMP ESP o simile in effetti, causando l'esecuzione del codice dallo stack. Questa esecuzione "diretta" del codice è impedita da DEP.

Ovviamente, l'esempio precedente non include il bypass di nessuna delle mitigazioni moderne (stack canaries, SafeSEH, DEP). Ciò non significa che sia globalmente impossibile, ma potrebbe essere impossibile in alcuni casi. Bypassare il DEP di solito implica programmazione orientata al ritorno - invece del codice stesso, i dati appositamente predisposti vengono messi in pila, che utilizza frammenti di funzioni già esistenti nell'immagine di processo (chiamati gadget) per eseguire il codice. Questo, a sua volta, viene mitigato da ASLR, rendendo gli indirizzi del gadget un po 'imprevedibili. Esistono anche tecniche per aggirare l'ASLR.

Se vuoi mettere le mani sullo sfruttamento di programmi reali, ti suggerisco corelanc0d3r come punto di partenza.

EDIT : sostituisce la parte che causa l'errore.

Iniezione di codice / L'esecuzione di codice è qualsiasi attacco che implica l'ingannare un nodo in un sistema distribuito nel codice in esecuzione specificato in un messaggio di rete che doveva essere trattato come semplice text / byte.

La parte arbitraria indica che la vulnerabilità consente all'autore dell'attacco di utilizzare la piena autorità del processo in esecuzione o di alcuni principi privilegiati come root .

given that modern OSes implement DEP and ASLR, how is this even feasible

L'iniezione di codice si basa su qualche altro tipo di vulnerabilità per iniettare il carico utile. Probabilmente stai pensando all'iniezione tramite overflow del buffer ma ci sono altri modi per iniettare il codice che i trucchi dello spazio degli indirizzi della memoria non aiuto contro.

L'iniezione di codice non significa necessariamente istruzioni di iniezione nel set di istruzioni del processore in un segmento di codice / dati. Può significare iniettare il codice sorgente in un linguaggio di scripting che il programma interpreta follemente . Ad esempio, iniezione shell comporta l'iniezione di byte che vengono passati a una shell.

Shell injection (or Command Injection[10])is named after Unix shells, but applies to most systems which allow software to programmatically execute a command line. Typical shell injection-related functions include system(), StartProcess(), and System.Diagnostics.Process.Start().

Alcuni sistemi hanno usato violazione delle stringhe * per cercare di mitigare le iniezioni di codice che non sono coperte da DEP / ASLR e aiuta ma non è infallibile: i bit di taint non sono serializzati quando le stringhe sono serializzate su file / I DB e, in manutenzione, ulteriori istruzioni non tenute vengono aggiunti a un programma per correggere i bug non di elevata visibilità che vengono rimossi per correggere le vulnerabilità della sicurezza a bassa visibilità.

The concept behind taint checking is that any variable that can be modified by an outside user (for example a variable set by a field in a web form) poses a potential security risk. If that variable is used in an expression that sets a second variable, that second variable is now also suspicious. The taint checking tool proceeds variable by variable until it has a complete list of all variables which are potentially influenced by outside input.

I sistemi che etichettano le stringhe in base al flusso di informazioni sono stati utilizzati anche per garantire la distribuzione sistemi che devono mescolare stringhe di diversa provenienza, ma il flusso di informazioni è più di un approccio tutto-o-niente: più difficile da riadattare su sistemi che non sono stati progettati attorno ad esso.

Information flow control protects information security by constraining how information is transmitted among objects and users of various security classes. These security classes are expressed as labels associated with the information or its containers.

Il controllo della contaminazione, sopra, è un tipo molto semplice di analisi del flusso di informazioni in cui le etichette sono limitate a (macchiate, non dipinte).