Subvert Code-signing Facilities
Attack Pattern ID: 68 (Standard Attack Pattern Completeness: Complete)Typical Severity: Very HighStatus: Draft
+ Description


Because languages use code signing facilities to vouch for code's identity and to thus tie code to its assigned privileges within an environment, subverting this mechanism can be instrumental in an attacker escalating privilege.

Any means of subverting the way that a virtual machine enforces code signing classifies for this style of attack. This pattern does not include circumstances through which a signing key has been stolen.

+ Attack Prerequisites

A framework-based language that supports code signing (such as, and most commonly, Java or .NET)

Deployed code that has been signed by its authoring vendor, or a partner.

The attacker will, for most circumstances, also need to be able to place code in the victim container. This does not necessarily mean that they will have to subvert host-level security, except when explicitly indicated.

+ Typical Likelihood of Exploit

Likelihood: Low

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


In old versions (prior to 3.0b4) of the Netscape web browser Attackers able to foist a malicious Applet into a client's browser could execute the "Magic Coat" attack. In this attack, the offending Applet would implement its own getSigners() method. This implementation would use the containing VM's APIs to acquire other Applet's signatures (by calling _their_ getSigners() method) and if any running Applet had privileged-enough signature, the malicious Applet would have inherited that privilege just be (metaphorically) donning the others' coats.


Some (older) web browsers allowed scripting languages, such as Javascript, to call signed Java code. In these circumstances, the browser's VM implimentation would choose not to conduct stack inspection across language boundaries (from called signed Java to calling Javascript) and would short-circuit "true" at the language boundary. Doing so meant that the VM would allow any (unprivileged) script to call privileged funcitons within signed code with impunity, causing them to fall prey to luring attacks.


The ability to load unsigned code into the kernel of earlier versions of Vista and bypass integrity checking is an example of such subversion. In the proof-of-concept, it is possible to bypass the signature-checking mechanism Vista uses to load device drivers.

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: High

Subverting code signing is not a trivial activity. Most code signing and verification schemes are based on use of cryptography and the attacker needs to have an understand of these cryptographic operations in good detail. Additionally the attacker also needs to be aware of the way memory is assigned and accessed by the container since, often, the only way to subvert code signing would be to patch the code in memory.

Finally, a knowledge of the platform specific mechanisms of signing and verifying code is a must.

+ Resources Required

The Attacker needs no special resources beyond the listed pre-requisities in order to conduct this style of attack.

+ Probing Techniques

Understanding, and possibly exploiting, the effect of certain flags or environment variables on code signing.

Introducing unmanaged code into a container-managed environment

+ Solutions and Mitigations

A given code signing scheme may be fallible due to improper use of cryptography. Developers must never roll out their own cryptography, nor should existing primitives be modified or ignored.

If an attacker cannot attack the scheme directly, he might try to alter the environment that affects the signing and verification processes. A possible mitigation is to avoid reliance on flags or environment variables that are user-controllable.

+ Attack Motivation-Consequences
  • Privilege Escalation
+ Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
325Missing Required Cryptographic StepTargeted
328Reversible One-Way HashTargeted
+ Related Vulnerabilities
Vulnerability IDRelationship Description

Multiple packages on Sun Solaris, including (1) NSS; (2) Java JDK and JRE 5.0 Update 8 and earlier, SDK and JRE 1.4.x up to 1.4.2_12, and SDK and JRE 1.3.x up to 1.3.1_19; (3) JSSE 1.0.3_03 and earlier; (4) IPSec/IKE; (5) Secure Global Desktop; and (6) StarOffice, when using an RSA key with exponent 3, removes PKCS-1 padding before generating a hash, which allows remote attackers to forge a PKCS #1 v1.5 signature that is signed by that RSA key and prevents these products from correctly verifying X.509 and other certificates that use PKCS #1.


verify.c in GnuTLS before 1.4.4, when using an RSA key with exponent 3, does not properly handle excess data in the digestAlgorithm.parameters field when generating a hash, which allows remote attackers to forge a PKCS #1 v1.5 signature that is signed by that RSA key and prevents GnuTLS from correctly verifying X.509 and other certificates that use PKCS, a variant of CVE-2006-4339.

+ Related Attack Patterns
NatureTypeIDNameDescriptionView(s) this relationship pertains toView\(s\)
ChildOfCategoryCategory232Exploitation of Privilege/Trust 
Mechanism of Attack (primary)1000
ParentOfAttack PatternAttack Pattern206Lifting signing key and signing malicious code from a production environment 
Mechanism of Attack (primary)1000
ParentOfAttack PatternAttack Pattern237Calling signed code from another language within a sandbox that allows this 
Mechanism of Attack (primary)1000
ParentOfAttack PatternAttack Pattern238Using URL/codebase / G.A.C. (code source) to convince sandbox of privilege 
Mechanism of Attack (primary)1000
+ Related Guidelines
  • Use Well-Known Cryptography Appropriately and Correctly

+ Purposes
  • Exploitation
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: High
+ Technical Context
Architectural Paradigms
+ Content History
John StevenCigital, Inc2007-02-10Initial core pattern content
Chiradeep B. ChhayaCigital, Inc2007-02-23Fleshed out pattern with extra content