Name Escaping a Sandbox by Calling Signed Code in Another Language
Summary The attacker may submit a malicious signed code from 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 A framework-based language that supports code signing and sandbox (such as Java, .Net, JavaScript, and Flash) Deployed code that has been signed by its authoring vendor, or a partner
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
Back to Top