COMMON ATTACK PATTERN ENUMERATION AND CLASSIFICATIONLive MITRE record

CAPEC-237

Escaping a Sandbox by Calling Code in Another Language

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.

Abstraction

Detailed

Typical severity

Very High

Likelihood of attack

Low

Understand the attack

What is this attack pattern?

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.

Execution flow

How does the attack proceed, step by step?

1

Explore

Probing

The attacker probes the target application to see whether calling code of another language is allowed within a sandbox.

Techniques used

  • The attacker probes the target application to see whether calling code of another language is allowed within a sandbox.

Analysis

The attacker analyzes the target application to get a list of cross code weaknesses in the standard libraries of the sandbox.

Techniques used

  • The attacker analyzes the target application to get a list of cross code weaknesses in the standard libraries of the sandbox.
2

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.

Techniques used

  • The attacker tries to explore the security weaknesses by calling malicious code of another language allowed by the sandbox.
3

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.

Techniques used

  • The attacker calls malicious code of another language to exploit the security weaknesses in the standard libraries.

Requirements

What does the attack require?

Prerequisites

  • Target application or infrastructure exposes an exploitable vulnerability surface.

Skills required

  • High: The attacker must have a good knowledge of the platform specific mechanisms of signing and verifying code. Most code signing and verification schemes are based on use of cryptography, the attacker needs to have an understand of these cryptographic operations in good detail.

Resources required

  • None: No specialized resources are required to execute this type of attack.

Impact

What does a successful attack lead to?

Bypass Protection Mechanism

Affected scopes: Access Control, Authorization

Execute Unauthorized Commands

Affected scopes: Authorization

Gain Privileges

Affected scopes: Accountability, Authentication, Authorization, Non-Repudiation

Defence

How is it prevented and mitigated?

1
Assurance: Sanitize the code of the standard libraries to make sure there is no security weaknesses in them.
2
Design: Use obfuscation and other techniques to prevent reverse engineering the standard libraries.
3
Assurance: Use static analysis tool to do code review and dynamic tool to do penetration test on the standard library.
4
Configuration: Get latest updates for the computer.

Real world

MITRE example instances

Example instance 1Detail
Exploit: Java/ByteVerify.C is a detection of malicious code that attempts to exploit a vulnerability in the Microsoft Virtual Machine (VM). The VM enables Java programs to run on Windows platforms. The Microsoft Java VM is included in most versions of Windows and Internet Explorer. In some versions of the Microsoft VM, a vulnerability exists because of a flaw in the way the ByteCode Verifier checks code when it is initially being loaded by the Microsoft VM. The ByteCode Verifier is a low level process in the Microsoft VM that is responsible for checking the validity of code - or byte code - as it is initially being loaded into the Microsoft VM. Java/ByteVerify.C attempts to download a file named "msits.exe", located in the same virtual directory as the Java applet, into the Windows system folder, and with a random file name. It then tries to execute this specific file. This flaw enables attackers to execute arbitrary code on a user's machine such as writing, downloading and executing additional malware. This vulnerability is addressed by update MS03-011, released in 2003.
CAPEC-237: Escaping a Sandbox by Calling Code in Another Language — DayBreach Saldırı Sözlüğü · DayBreach