Page History

Java provides several APIs that allow outside external programs to monitor a running Java program. These APIs also permit the Java program to be monitored remotely by programs on distinct hosts. Such features are convenient for debugging the program or fine-tuning its performance. However, if a Java program is deployed in production with remote monitoring enabled, an attacker can connect to the JVM and inspect its behavior and data, including potentially sensitive information. An attacker can also exert some control over the program's behavior. Consequently, remote monitoring must be disabled when running a Java program in production.

...

The JVMTI contains extensive facilities to find out learn about the internals of a running JVM, including facilities to monitor and modify a running Java program. These facilities are rather low level and require the use of the Java Native Interface (JNI) and C Language language programming. However, they provide the opportunity to access fields that would not normally be accessibleinaccessible. Also, there are facilities that can change the behavior of a running Java program (for example, threads can be suspended or stopped). The JVMTI profiling tools can also measure the time that a thread takes to execute, leaving applications vulnerable to timing attacks.

...

The Java Platform Debugger Architecture (JPDA) builds on the JVMTI and provides high-level facilities for debugging Java systems while they are running \[[JPDA 2004|AA. Bibliography#JPDA 2004]\]. 

The JDPA JPDA facilities are similar to the reflection API, which is described in rule SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields. In particular, the JPDA provides methods to get and set field and array values. Access control is not enforced, so that even the values of private fields can be set by a remote process via the JPDA.

...

These facilities can be used either locally (from on the machine that runs the JVM) or remotely. Local monitoring and management is enabled by default when a JVM is started; remote monitoring and management is not. For a JVM to be monitored and managed remotely, it must be started with various system properties set (either on the command line or in a configuration file).

...

There are also provisions to require proper authentication of the remote server. However, users may start a JVM with remote monitoring and management enabled, but with no security, and ; this would leave the JVM open to attack from by outsiders. Although accidently enabling remote monitoring and management is unlikely, users might not realize that starting a JVM so enabled, without any security, could leave their JVM exposed to attack.

...

The JPDA host can serve either as a server or as a client. When the attacker cannot sniff the network to determine the identity of machines that use the JPDA host (for example, through the use of a secure channel), specify the JPDA host as the client and the debugger application as the server by changing the value of the server argument to n.

...

ENV05-EX0: A Java program may be remotely monitored using any of these technologies when if it can be guaranteed that no program outside the local trust boundary can access the program. For example, if the program lives on a local network that is both completely trusted and disconnected from any larger untrusted networks, including the Internet, remote monitoring is permitted.

...

Automated Detection

Not This rule is not amenable to automated static analysis.

Bibliography

Related Vulnerabilities

CVE-2010-4495 describes a vulnerability in the TIBCO ActiveMatrix product line where a flaw in JMX connection processing allowed remote users to execute arbitrary code, cause denial of service or obtain potentially sensitive information.

Bibliography

...