You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 55 Next »

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 if the class file is conforming. The class file could have been created by some other process, or a malicious hacker could tamper with a conforming class file.

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

Users often assume that Java class files that have been obtained from a trustworthy source will be conforming and, consequently, safe for execution. They might then misconstrue bytecode verification as a superfluous activity in such cases and. Consequently, they may disable bytecode verification, severely undermining Java's safety and security guarantees.

Noncompliant Code Example

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

java -Xverify:none ApplicationName

Compliant Solution

Bytecode verification happens by default in most JVM implementations. Bytecode verification is also performed automatically when a class loader loads a class dynamically.

If a JVM has bytecode verification disabled, the -Xverify:all flag can be specified on the command line as shown in this compliant solution.

java -Xverify:all ApplicationName

Exceptions

ENV10-EX1: On Java 2 systems, classes that are loaded by the primordial class loader (that loads classes from the boot class path) are not required to perform bytecode verification.

Risk Assessment

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

Guideline

Severity

Likelihood

Remediation Cost

Priority

Level

ENV10-J

high

likely

low

P27

L1

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

[[Oaks 2001]] The Bytecode Verifier
[[Pistoia 2004]] Section 7.3, The Class File Verifier


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

  • No labels