Qual è il punto di sfuggire alla sandbox di un interprete?

Question

Qual è il punto di sfuggire alla sandbox di un interprete?

#1 da (2 voti)

1

Supponendo che l'autore dell'attacco abbia già un'esecuzione di codice (che è il caso di ogni interprete di escape sandbox che conosco), non potrebbe semplicemente usare una funzione / metodo (come Runtime.getRuntime (). exec () in Java o os.system () in Python) per eseguire qualsiasi comando di shell nel contesto dell'utente che sta eseguendo l'interprete?

A che punto è la ricerca di una vulnerabilità nativa difficile da trovare in un programma sorgente complesso, a volte chiuso e lo sviluppo di un exploit che deve bypassare più mitigazioni per ottenere lo stesso risultato (probabilmente con un'affidabilità non del 100%)?

sandbox exploit exploit-development

posta Not Now 02.04.2018 - 06:59

fonte

1 risposta

Leggi altre domande sui tag sandbox exploit exploit-development

Come posso utilizzare una connessione VPN su Eduroam? [chiuso] Le primitive crittografiche simmetriche offrono sia integrità che riservatezza?

score 2 · Accepted Answer

Considera JavaScript. La maggior parte delle pagine web in questi giorni serve alcuni JS. Il tuo browser esegue questo JS, senza alcun suggerimento dell'utente o altra autorizzazione (a meno che tu non usi un'estensione come NoScript), ogni volta che carica una pagina che contiene script. Il motore JS del browser è estremamente potente; puoi (ad esempio) emulare un intero computer Linux x86 in esso . Può anche definire classi, inserire script esterni, avviare worker in background e così via. Tuttavia, questo è, per la maggior parte, sicuro, perché il browser sandbox JavaScript. Non puoi, senza l'escape di una sandbox , fare cose come "modificare i documenti dell'utente" o "distribuire qualcosa di dannoso come ransomware" o "ottenere una shell sul sistema operativo che esegue il browser".

Un altro esempio, pertinente ai tuoi esempi, è la sandbox dell'applet Java . Le applet Java sono usate raramente oggi (in parte perché le persone continuavano a trovare escape di sandbox per loro, quindi non era sicuro abilitarle!) Ma per un po 'erano piuttosto popolari perché ti lasciavano fare cose che erano sia molto più avanzate e un po' più veloci rispetto ai motori JS del giorno (e ti permettono di scrivere codice in Java, che anche allora era molto più maturo di JS). Le applet sono realizzate in bytecode Java ed eseguite utilizzando la JVM, come qualsiasi altra applicazione Java. La differenza è che sono sandboxed in modo che possano fare solo le cose considerate sicure per una pagina web. Ad esempio:

• They cannot access client resources such as the local filesystem, executable files, system clipboard, and printers.

• They cannot connect to or retrieve resources from any third party server (any server other than the server it originated from).

Queste protezioni significano che il codice in esecuzione in un'applet non può semplicemente invoca Runtime.getRuntime().exec() ; anche se la classe e le funzioni esistono nella JVM e possono essere chiamate dalle normali app Java, provare a chiamarle da un'applet sandbox avviene attraverso un qualche tipo di SecurityException . Se vuoi farlo senza ottenere un'eccezione (ad esempio, per eseguire malware), devi uscire dalla sandbox.