Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

When Java source code is compiled, it is converted into bytecode, saved in one or more class files, and executed by the Java Virtual Machine (JVM). Java class files may be compiled on one machine and executed on another machine. A properly generated class file is said to be conforming. When the JVM loads a class file, it has no way of knowing whether the class file is conforming. The class file could have been created by some other process, or an attacker may have tampered with a conforming class file.

The Java bytecode verifier is an internal component of the JVM and that is responsible for detecting non-confirming nonconforming Java codebytecode. Ensures It ensures that the class file is in the proper Java class format, that illegal type casts are not performed and prevents operand stack overflows or underflows.

Noncompliant Code Example

avoided, that operand stack underflows are impossible, and that each method eventually removes from the operand stack everything pushed by that method.

Users often assume that Java class files obtained from a trustworthy source will be conforming and, consequently, safe for execution. This belief can erroneously lead them to see bytecode verification as a superfluous activity for such classes. Consequently, they might disable bytecode verification, undermining Java's safety and security guarantees. The bytecode verifier must not be suppressed.

Noncompliant Code Example

The bytecode verification process runs by default. The -Xverify:none flag on the JVM command line suppresses the verification process. This noncompliant code example uses the flag to disable bytecode verification: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.

Code Block
bgColor#FFcccc

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.

java -Xverify:none ApplicationName

Compliant Solution

Most JVM implementations perform bytecode verification by default; it is also performed during dynamic class loading.

Specifying Alternatively, to force bytecode verification when the unmodified class is loaded, the -Xverify:all flag can be specified on the java command line.command line requires the JVM to enable bytecode verification (even when it would otherwise have been suppressed), as shown in this compliant solution:

Code Block
bgColor#ccccff
java -Xverify:all ApplicationName

Exceptions

ENV04-J-EX0: 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 is permitted to omit bytecode verification of classes loaded from the boot class path) are not required to perform bytecode verification. The verification is automatically performed when a classloader loads a class dynamically.. These system classes are protected through platform and file system protections rather than by the bytecode verification process.

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 Bytecode verification ensures that the bytecode contains many of the security checks mandated by the Java Language Specification. This code could bypass checks that are normally expected to be performed by Java code, thereby compromising securityOmitting the verification step could permit execution of insecure Java code.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC36

ENV04-J

medium

High

probable

Likely

low

Low

P12

P27

L1

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation Static checking of this rule on the CERT website.

References

Wiki Markup
\[[Oaks 01|AA. Java References#Oaks 01]\] The Bytecode Verifier
\[[Pistoia 04|AA. Java References#Pistoia 04]\] Section 7.3, The Class File Verifier

is not feasible in the general case.

Android Implementation Details

Under the default settings, bytecode verification is enabled on the Dalvik VM. To change the settings, use the adb shell to set the appropriate system property: for example, adb shell setprop dalvik.vm.dexopt-flags v=a or pass -Xverify:all as an argument to the Dalvik VM.

Bibliography

[Oaks 2001]

"The Bytecode Verifier"

[Pistoia 2004]

Section 7.3, "The Class File Verifier"


...

Image Added Image Added Image AddedOBJ36-J. Provide mutable classes with a clone method      00. Security (SEC)      01. Declarations and Initialization (DCL)