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
Description
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.
Description
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.
Description
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.
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.
CVE-2006-4790
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.
Vision and Technical Leadership provided by Cigital, Inc.
This Web site is hosted by The MITRE Corporation.
Copyright 2009, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.