Assuming that the attacker already has code execution (which is the case of every interpreter sandbox escape exploit I know of), couldn't he just use a function/method (like Runtime.getRuntime().exec() in Java or os.system() in Python) to execute any shell command in the context of the user that is running the interpreter?

What is the point of searching for a difficult to find native vulnerability in a complex, sometimes closed source program and developing an exploit that has to bypass multiple mitigations to achieve the same result (probably with a non-100% reliability)?

  • I don't understand what you are asking: If the attacker can run arbitrary code from within the interpreter as you claim then he has already escaped the sandbox, because the sandbox is there to limit exactly what can be done. Maybe a specific example of an existing exploit could make your question more clear. Apr 2, 2018 at 5:36
  • Here is an example: benmmurphy.github.io/blog/2015/10/21/…. The exploit is here: github.com/benmmurphy/JavaPlayground/blob/master/ZDI-13-075/…. The attacker needs to define a whole class (and import the necessary classes), which I guess is equivalent to arbitrary code execution. The vulnerability has a ZDI advisory, which means that the exploit is supposed to have such a high impact that ZDI paid for it - still I can't get the point. What am I missing?
    – Not Now
    Apr 2, 2018 at 5:43
  • 1
    "What am I missing?" - you are missing that the attacker has not achieved already arbitrary code execution as you assume since the sandbox limits what code can be executed. Apr 2, 2018 at 6:04

1 Answer 1


Consider JavaScript. Most web pages these days serve some JS. Your browser executes this JS, without any user prompting or other permission (unless you use an extension like NoScript), any time it loads a page that contains script. The browser's JS engine is extremely powerful; you can (for example) emulate an entire x86 Linux computer in it. It can also define classes, pull in external scripts, start background workers, and so on. Yet this is, for the most part, safe to do, because the browser sandboxes JavaScript. You cannot, without a sandbox escape, do things like "modify the user's documents" or "deploy something malicious such as ransomware" or "get a shell on the OS running the browser".

Another example, relevant to your examples, is the Java applet sandbox. Java applets are rarely used today (partially because people kept finding sandbox escapes for them, so it wasn't safe to enable!) but for a while they were quite popular because they let you do stuff that was both much more advanced and somewhat faster than the JS engines of the day (and they let you write code in Java, which even then was much more mature than JS). Applets are made of Java bytecode and execute using the JVM, same as any other Java application. The difference is, they are sandboxed so that they can only do things considered safe for a web page to do. For example:

• 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).

These protections mean that code running in an applet cannot simply invoke Runtime.getRuntime().exec(); even though that class and functions exist in the JVM, and can be called from normal Java apps, trying to call them from a sandboxed applet would through some kind of SecurityException. If you want to do that without getting an exception (for example, to run some malware), you need to escape the sandbox.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .