Home > CAPEC List > CAPEC-237: Calling Signed Code From Another Language Within A Sandbox Allow This (Version 2.10)  

CAPEC-237: Calling Signed Code From Another Language Within A Sandbox Allow This

 
Calling Signed Code From Another Language Within A Sandbox Allow This
Definition in a New Window Definition in a New Window
Attack Pattern ID: 237
Abstraction: Standard
Status: Draft
Completeness: Complete
Presentation Filter:
+ 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 behave. 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.

+ Attack Execution Flow
Explore
  1. Probing:

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

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

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

    env-All

    Indicators

    IDTypeIndicator DescriptionEnvironments
    1Positive

    The target application allows calling signed code from another language within a sandbox.

    env-All

    Outcomes

    IDTypeOutcome Description
    1Success
    The attacker knows that the target application is calling signed code from another language within a sandbox.
  2. Analysis:

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

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

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

    env-All

    Indicators

    IDTypeIndicator DescriptionEnvironments
    1Positive

    The standard library of the sandbox has some cross code security weaknesses.

    env-All

    Outcomes

    IDTypeOutcome Description
    1Success
    The attacker gets a list of cross code security weaknesses in the standard libraries.

    Security Controls

    IDTypeSecurity Control Description
    1Preventative
    Sanitize the code of the standard libraries to make sure there is no security weaknesses in them.
    2Preventative
    If possible, use obfuscation and other techniques to prevent reverse engineering the libraries.
Experiment
  1. Verify the exploitable security weaknesses:

    The attacker tries to craft malicious signed code from another language allowed by the sandbox to verify the security weaknesses of the standard libraries found in the Explore phase.

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

    The attacker tries to explore the security weaknesses by calling malicious signed code from another language allowed by the sandbox.

    env-Web

    Outcomes

    IDTypeOutcome Description
    1Success
    The attacker identifies a list exploitable security weaknesses in the standard libraries.

    Security Controls

    IDTypeSecurity Control Description
    1Preventative
    Sanitize the code of the standard libraries to make sure there are no security weaknesses in them.
Exploit
  1. Exploit the security weaknesses in the standard libraries:

    The attacker calls signed malicious code from 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.

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

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

    env-All

    Outcomes

    IDTypeOutcome Description
    1Success
    The attacker escapes the sandbox to obtain access to privileges that were not intentionally exposed by the sandbox.

    Security Controls

    IDTypeSecurity Control Description
    1Preventative
    Sanitize the code of the standard libraries to make sure there is no security weaknesses in them.
+ Attack 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

+ Typical Severity

Very High

+ Typical Likelihood of Exploit

Likelihood: Low

+ Methods of Attack
  • Analysis
  • API Abuse
+ Examples-Instances

Description

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. Exploit: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.

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: 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

No special resource is required.

+ Solutions and Mitigations

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.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Access_Control
Authorization
Bypass protection mechanism
Authorization
Execute unauthorized code or commands
Run Arbitrary Code
Accountability
Authentication
Authorization
Non-Repudiation
Gain privileges / assume identity
+ Purposes
  • Exploitation
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: High
+ Technical Context
Architectural Paradigms
All
Frameworks
All
Platforms
All
Languages
Java
ASP.NET
C#
JSP
Other
+ References
[R.237.1] J. Cappos, J. Rasley, J. Samuel, I. Beschastnikh, C. Barsan, A. Krishnamurthy and T. Anderson. "Retaining Sandbox Containment Despite Bugs in Privileged Memory-Safe Code". The 17th ACM Conference on Computer and Communications Security (CCS '10). 2010.
[R.237.2] "Malware Protection Center: Threat Research and Response". Exploit: Java/ByteVerify.C. Microsoft Corporation. 2007. <http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Exploit%3AJava%2FByteVerify.C>.
+ Content History
Submissions
SubmitterOrganizationDateSource
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team
More information is available — Please select a different filter.
Page Last Updated or Reviewed: May 01, 2017