perché gli exploit dello shellcode Javascript non possono essere corretti tramite "prevenzione esecuzione dati"?

Question

L'articolo di wikipedia "heap spraying" suggerisce che molti exploit javascript implicano il posizionamento di uno shellcode da qualche parte nel codice eseguibile dello script o nella memoria dello spazio di dati e quindi l'esecuzione dell'interprete e l'esecuzione. Quello che non capisco è, perché l'intero heap dell'interprete non può essere contrassegnato come "dati" in modo che l'interprete possa impedire l'esecuzione dello shellcode da parte di DEP? Nel frattempo l'esecuzione di bytecode derivato da javascript sarebbe stata eseguita dalla macchina virtuale che non gli avrebbe permesso di modificare la memoria appartenente all'interprete (questo non funzionerebbe su V8 ​​che sembra eseguire codice macchina, ma probabilmente funzionerebbe su Firefox che usa qualche tipo di bytecode).

Immagino che quanto sopra sembra banale e probabilmente qualcosa di simile in realtà è stato fatto. Quindi, sto cercando di capire dove si trova il difetto nel ragionamento, o il difetto nelle implementazioni di interpreti esistenti. Per esempio. l'interprete fa affidamento sull'allocazione di memoria del sistema invece di implementare la propria allocazione interna quando javascript richiede memoria, rendendo così eccessivamente difficile separare la memoria che appartiene all'interprete e al javascript? O perché i metodi basati su DEP non possono eliminare completamente i codici shell?

Answer 1

Per rispondere alla tua domanda dobbiamo prima definire, Data Execution Prevention, Just In Time Compilation e JIT spruzzo.

Prevenzione esecuzione dati è una funzione di sicurezza che vieta l'esecuzione di codice da un'area di memoria non eseguibile. DEP può essere implementato da meccanismi hardware come il bit NX e/o dal meccanismo del software aggiungendo i controlli di runtime.

I compilatori Just In Time (JIT) sono compilatori dinamici che convertono i codici byte durante il runtime in codice macchina. L'obiettivo è combinare i vantaggi del codice interpretato e la velocità del codice compilato. Dovrebbe compilare i metodi solo se il tempo extra impiegato nella compilazione può essere ammortizzato dal guadagno di prestazioni atteso dal codice compilato. [1]

JIT spruzzare è il processo di costringere il motore JIT di scrivere molte pagine eseguibili con shellcode incorporato.

[....]

Per esempio, una dichiarazione JavaScript come “var x = 0x41414141 + 0x42424242;” potrebbe essere compilato per contenere due 4 costanti byte nell'immagine eseguibile (ad esempio, “mov eax, 0x41414141; mov ecx, 0x42424242; aggiungi eax, ecx "). Avvia l'esecuzione nel mezzo di queste costanti, viene rivelato un flusso di istruzioni completamente diverso.

[....]

L'intuizione fondamentale è che il JIT è prevedibile e deve copiare alcune costanti alla pagina eseguibile. Data un'istruzione uniforme (ad esempio una somma lunga o qualsiasi pattern ripetuto), tali costanti possono codificare piccole istruzioni e quindi controllare il flusso fino alla posizione della costante successiva. [2]

Le tecniche avanzate, oltre lo scopo di questa risposta, devono quindi essere utilizzate per trovare l'indirizzo del blocco spruzzato JIT e attivare l'exploit.

Ora dovrebbe essere chiaro che

Se il codice dell'attaccante viene generata da un motore JIT sarà anche risiedere nella zona eseguibile. In altre parole, DEP non è coinvolto nella protezione del codice emesso dal compilatore JIT. [3]

Riferimenti

[1] A Dynamic Optimization Framework for a Java Just-in-Time Compiler

[2] Interpreter Exploitation: Pointer Inference and JIT Spraying

[3] JIT spraying and mitigations