The bytecode verifier is an internal component of the JVM and is responsible for detecting non-confirming Java code. Ensures that the class file is in proper format, that illegal type casts are not performed and prevents operand stack overflows or underflows.
Noncompliant Code Example
In this noncompliant code example, two classes, Ssn
and SsnVerify
are defined. If at some later time, the programmer changes the access modifier of the ssn
field from public
to private
, a possibility exists that only the modified Ssn
class is recompiled but the SsnVerify
class is overlooked. As a result, SsnVerify
can now illegally access the private ssn
field of the Ssn
class.
package ssnvault.values; public class Ssn { public String ssn = "001 01 0001"; } package ssnvault.values; public class SsnVerify { public static void main(String[] args) { Ssn number = new Ssn(); System.out.println("Please enter last four digits of your SSN:"); //perform verification } }
Version Specific Details
The behavior described in the Noncompliant Code Example has been demonstrated in Java 1.5.0 versions running on Mac OS X Tiger, Solaris 10/Sparc64, and Ubuntu Linux 8.04, but not in Java 1.6.0 versions running on Windows XP or Linux (unless the target version of both class files is specified as 1.4 or earlier).
Compliant Solution
It is vital to re-compile both Ssn
and SsnVerify
classes so that the bytecode verifier can be applied to detect the non-conforming code.
Alternatively, to force bytecode verification when the unmodified class is loaded, the -Xverify:all
flag can be specified on the java
command line.
The verification process is automatically initiated unless the -Xverify:none
flag is specified on the command line. On Java 2 systems, classes loaded by the primordial class loader (that loads classes from the boot class path) are not required to perform bytecode verification. The verification is automatically performed when a classloader loads a class dynamically.
Risk Assessment
If the bytecode verifier is not applied to all code then code could be loaded into a java system that does not conform to the Java Language Specification. This code could bypass checks that are normally expected to be performed by Java code, thereby compromising security.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SEC36-J |
medium |
probable |
low |
P12 |
L1 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[Oaks 01]] The Bytecode Verifier
[[Pistoia 04]] Section 7.3, The Class File Verifier
OBJ36-J. Provide mutable classes with a clone method 00. Security (SEC) 01. Declarations and Initialization (DCL)