Page History

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 Java Virtual Machine (JVM) and JVM that is responsible for detecting non-confirming nonconforming Java bytecode. It ensures that the class file is in the proper Java class format, that illegal type casts are not performed, and it prevents operand stack overflows or underflows. Users sometime assume that code 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 is will be conforming and, consequently, safe for execution. Bytecode verification may be misconstrued This belief can erroneously lead them to see bytecode verification as a superfluous activity in such cases and consequently, for such classes. Consequently, they might disable bytecode verification, undermining Java's safety and security guarantees may be severely undermined. The bytecode verifier must not be suppressed.

Noncompliant Code Example

The bytecode verification process is automatically initiated unless the runs by default. The -Xverify:none flag is specified on the JVM command line suppresses the verification process. This  This noncompliant code example uses this the flag to disable bytecode verification.:

java -Xverify:none ApplicationName

Compliant Solution

Bytecode Most JVM implementations perform bytecode verification happens by default in most implementations. The verification is automatically performed when a class loader loads a class dynamically.; it is also performed during dynamic class loading.

Specifying If it does not, the -Xverify:all flag can be specified 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

EX1ENV04-J-EX0: 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. These system classes are protected through platform and file system protections rather than by the bytecode verification process.

Risk Assessment

The code that is not subject to bytecode verification can bypass security checks that are normally expected to be performed by Java code.

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 insecure Java code.

Automated Detection

TODO

Related Vulnerabilities

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

References

\[[Oaks 2001|AA. Java References#Oaks 01]\] The Bytecode Verifier
\[[Pistoia 2004|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

...

Image Added Image Added Image AddedENV09-J. Limit remote uses of JVM Monitoring and Managing      01. Runtime Environment (ENV)      02. Platform Security (SEC)