Name |
Escaping a Sandbox by Calling Code in Another Language |
|
Likelyhood of attack |
Typical severity |
Low |
Very High |
|
Summary |
The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries. |
Prerequisites |
|
Execution Flow |
Step |
Phase |
Description |
Techniques |
1 |
Explore |
[Probing] The attacker probes the target application to see whether calling code of another language is allowed within a sandbox. |
- The attacker probes the target application to see whether calling code of another language is allowed within a sandbox.
|
2 |
Explore |
[Analysis] The attacker analyzes the target application to get a list of cross code weaknesses in the standard libraries of the sandbox. |
- The attacker analyzes the target application to get a list of cross code weaknesses in the standard libraries of the sandbox.
|
3 |
Experiment |
[Verify the exploitable security weaknesses] The attacker tries to craft malicious code of another language allowed by the sandbox to verify the security weaknesses of the standard libraries found in the Explore phase. |
- The attacker tries to explore the security weaknesses by calling malicious code of another language allowed by the sandbox.
|
4 |
Exploit |
[Exploit the security weaknesses in the standard libraries] The attacker calls malicious code of another language to exploit the security weaknesses in the standard libraries verified in the Experiment phase. The attacker will be able to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. |
- The attacker calls malicious code of another language to exploit the security weaknesses in the standard libraries.
|
|
Solutions | Assurance: Sanitize the code of the standard libraries to make sure there is no security weaknesses in them. Design: Use obfuscation and other techniques to prevent reverse engineering the standard libraries. Assurance: Use static analysis tool to do code review and dynamic tool to do penetration test on the standard library. Configuration: Get latest updates for the computer. |
Related Weaknesses |
CWE ID
|
Description
|
CWE-693 |
Protection Mechanism Failure |
|
Related CAPECS |
CAPEC ID
|
Description
|
CAPEC-480 |
An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks. |
|