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 could tamper with a conforming class file.
The Java bytecode verifier is an internal component of the JVM that is responsible for detecting non-conforming Java bytecode. It ensures that the class file is in the proper Java class format, that illegal type casts are 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 could disable bytecode verification, undermining Java's safety and security guarantees.
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.
java -Xverify:none ApplicationName
Compliant Solution
Most JVM implementations perform bytecode verification by default; it is also performed during dynamic class loading.
Specifying the -Xverify:all flag on the command line requires the JVM to enable bytecode verification (even when it would otherwise have been suppressed), as shown in this compliant solution.
java -Xverify:all ApplicationName
Exceptions
ENV10-EX1: On Java 2 systems, the primordial class loader is permitted to omit bytecode verification of classes loaded from the boot class path. These system classes are protected through platform and file system protections, rather than by the bytecode verification process.
Risk Assessment
Bytecode verification ensures that the bytecode contains many of the security checks mandated by the Java Language Specification. Omitting the verification step could permit execution of unsafe Java code.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
ENV10-J |
high |
likely |
low |
P27 |
L1 |
Automated Detection
Static checking of this rule is not feasible in the general case.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="da5eb007-c3f9-4384-bfe1-661d5d070344"><ac:plain-text-body><![CDATA[ |
[[Oaks 2001 |
AA. Bibliography#Oaks 01]] |
The Bytecode Verifier |
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="0a081adb-8c9a-4c98-903b-abbb2627ba38"><ac:plain-text-body><![CDATA[ |
[[Pistoia 2004 |
AA. Bibliography#Pistoia 04]] |
Section 7.3, The Class File Verifier |
]]></ac:plain-text-body></ac:structured-macro> |
ENV08-J. Limit remote uses of JVM Monitoring and Managing 15. Runtime Environment (ENV) 16. Serialization (SER)