Page History

Java provides several APIs that allow outside 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 handy 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 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 programming. However, they provide the opportunity to access fields that would not normally be accessible. 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 JVMTI works by using agents that communicate with the running JVM. These agents must be loaded at JVM startup and are usually specified via one of the command line options {{–agentlib:}} or {{–agentpath:}}. However, agents can be specified in environment
variables, although this feature can be disabled where security is a concern. The JVMTI is always enabled, and JVMTI agents may run under the default security manager without requiring any permissions to be granted. More work needs to be done to determine under
exactly what circumstances the JVMTI can be misused.

Java Platform Debugger Architecture (JPDA)

The JVMJava ToolPlatform Interface \[[JVMTI 2006|AA. Bibliography#JVMTI 06]\] provides facilities for querying the internals of a JVM and includes methods for monitoring and modifying the behavior of a running Java program. These low level facilities require the use of the Java Native Interface (JNI) and C language programming. The JVM Tool Interface is typically used by development and monitoring tools. 

From a security point of view, the JVMTI provides access to fields that are normally inaccessible. The interface also provides facilities for changing the behavior of a running Java program; for example, threads can be suspended or stopped. The JVMTI profiling tools can measure the time that a thread takes to execute, leaving applications vulnerable to timing attacks.

Java Platform Debugger Architecture (JPDA)

The Java Platform Debugger Architecture (JPDA) builds on the JVMTI and provides highlevel facilities for debugging running Java systems \[[JPDA 2004|AA. Bibliography#JPDA 2004]\]. These include facilities similar to the reflection facilities described above for inspecting and modifying field values. In particular, there are methods to get and set field and array values. Access control is not enforced so, for example, even the values of private fields can be set.

Introducing the default security manager means that various permissions must be granted in order for debugging to take place. The following policy file was used to run the JPDS Trace demonstration under the default security manager:

grant {
  permission java.io.FilePermission "traceoutput.txt", "read,write";
  permission java.io.FilePermission "C:/Program Files/Java/jdk1.5.0_04/lib/tools.jar", "read";
  permission java.io.FilePermission "C:/Program", "read,execute";
  permission java.lang.RuntimePermission "modifyThread";
  permission java.lang.RuntimePermission "modifyThreadGroup";
  permission java.lang.RuntimePermission "accessClassInPackage.sun.misc";
  permission java.lang.RuntimePermission "loadLibrary.dt_shmem";
  permission java.util.PropertyPermission "java.home", "read";
  permission java.net.SocketPermission "<localhost>", "resolve";
  permission com.sun.jdi.JDIPermission "virtualMachineManager";
};

The Java Platform Debugger Architecture (JPDA) \[[JPDA 2004|AA. Bibliography#JPDA 04]\] builds on the JVM Tool Interface. It provides high-level facilities for debugging running Java programs, often used for debugging programs running in remote environments.

The JDPA facilities are similar to the reflection facilities \[[Reflection 2006|AA. Bibliography#Reflection 06]\] used for inspecting and modifying field values. In particular, it is possible to get or set the values of fields. Access control is not enforced, so, for example, even the values of {{private}} fields can be accessed or modified.

As JPDA supports remote debugging, which means that a remote host can access the debugger. An attacker can exploit this feature unless appropriate protection is enabled. A security manager can ensure that only known, trusted hosts are given permissions to use the debugger interface.

Java SE Monitoring and Management features

Java contains extensive facilities for monitoring and managing a JVM \[[JMX 2006|AA. Bibliography#JMX 2006]\]. In particular, the Java Management Extension (JMX) API enables the monitoring and control of class loading, thread state and stack traces, deadlock detection, memory usage, garbage collection, operating system information, and other operations \[[Sun 04a|AA. Bibliography#Sun 04a]\]. There are also facilities for logging monitoring and management. A running JVM may be monitored and managed remotely.

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 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, for example, even the values of private fields can be set by a remote process via the JPDA.

Introducing the default security manager means that various permissions must be granted in order for debugging to take place. The following policy file was used to run the JPDS Trace demonstration under the default security manager:

grant {
  permission java.io.FilePermission "traceoutput.txt", "read,write";
  permission java.io.FilePermission "C:/Program Files/Java/jdk1.5.0_04/lib/tools.jar", "read";
  permission java.io.FilePermission "C:/Program", "read,execute";
  permission java.lang.RuntimePermission "modifyThread";
  permission java.lang.RuntimePermission "modifyThreadGroup";
  permission java.lang.RuntimePermission "accessClassInPackage.sun.misc";
  permission java.lang.RuntimePermission "loadLibrary.dt_shmem";
  permission java.util.PropertyPermission "java.home", "read";
  permission java.net.SocketPermission "<localhost>", "resolve";
  permission com.sun.jdi.JDIPermission "virtualMachineManager";
};

Because JPDA supports remote debugging, a remote host can access the debugger. An attacker can exploit this feature to study sensitive information or modify the behavior of a running Java application unless appropriate protection is enabled. A security manager can ensure that only known, trusted hosts are given permissions to use the debugger interface.

Java SE Monitoring and Management features

Java contains extensive facilities for monitoring and managing a JVM \[[JMX 2006|AA. Bibliography#JMX 2006]\]. In particular, the Java Management Extension (JMX) API enables the monitoring and control of class loading, thread state and stack traces, deadlock detection, memory usage, garbage collection, operating system information, and other operations \[[Sun 04a|AA. Bibliography#Sun 04a]\]. There are also facilities for logging monitoring and management.

The Java SE Monitoring and Management features fall into four broad categories:

• The Java Management Extensions (JMX) technology: This technology serves as the underlying interface for local and remote monitoring and management.
• Instrumentation for the Java Virtual Machine (JVM): These facilities enable out-of-the-box monitoring and management of the JVM and are based on the JMX specification.
• Monitoring and Management Application Programming Interfaces (API): These facilities use the java.lang.management package to provide the monitoring and management interface. Applications can use this package to monitor themselves or to let JMX technology compliant tools to monitor and manage them.
• Monitoring and Management tools: Tools such as Jconsole implement the JMX interface to provide monitoring and management facilities.

These facilities can be used either locally (from 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).

 When remote monitoring and management is enabled, access is password-controlled by default. However, password control can be disabled. Disabling password authentication is insecure because any user who can discover the port number that the JMX service is listening on can monitor and control the Java applications running on the JVM \[[JMXG 2006|AA. Bibliography#JMXG 06]\].

The JVM Remote monitoring and management facility uses a secure communication channel (SSL) by default. However, if an attacker can start a bogus RMI registry on the monitored machine before the legitimate RMI registry is started, JMX passwords can be intercepted. Also, SSL can be disabled when using remote monitoring and management which could, again, compromise security. See The Java SE Monitoring and Management Guide \[[JMXG 2006|AA. Bibliography#JMXG 06]\] for further details and for avoidance strategies.

There are also provisions to require 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). Also, there are provisions for the monitoring and management to be done securely (by passing the information using SSL, for example) and to require proper authentication of the remote server. However, users may start a JVM with remote monitoring and management enabled, but with no security for their own purposes, and this would leave the JVM open to compromise attack from outsiders. Although a user could not easily turn on remote monitoring and management by accident, they might not realize that starting a JVM so enabled, without any security also switched on, could leave their JVM exposed to outside abuse.

The Java SE Monitoring and Management features fall into four broad categories:

• The Java Management Extensions (JMX) technology: This technology serves as the underlying interface for local and remote monitoring and management.
• Instrumentation for the Java Virtual Machine (JVM): These facilities enable out-of-the-box monitoring and management of the JVM and are based on the JMX specification.
• Monitoring and Management Application Programming Interfaces (API): These facilities use the java.lang.management package to provide the monitoring and management interface. Applications can use this package to monitor themselves or to let JMX technology compliant tools to monitor and manage them.
• Monitoring and Management tools: Tools such as Jconsole implement the JMX interface to provide monitoring and management facilities.

The JMX API provides the underlying facilities both for inspecting applications running in a JVM, as well as for controlling their operation \[[JMX 2006|AA. Bibliography#JMX 06]\]. These facilities can be used either locally (from the machine that runs the JVM) or remotely. If exploited, the monitoring and management facilities can seriously compromise the security of Java applications. For example, an attacker can obtain information about the number of classes loaded and threads running, thread state along with traces of live threads, system properties, VM arguments, and memory consumption.

Local monitoring and management is enabled by default when a JVM is started; remote monitoring and management is not. When remote monitoring and management is enabled, access is password-controlled by default. However, password control can be disabled. Disabling password authentication is insecure because any user who can discover the port number that the JMX service is listening on can monitor and control the Java applications running on the JVM \[[JMXG 2006|AA. Bibliography#JMXG 06]\].

The JVM Remote monitoring and management facility uses a secure communication channel (SSL) by default. However, if an attacker can start a bogus RMI registry on the monitored machine before the legitimate RMI registry is started, JMX passwords can be intercepted. Also, SSL can be disabled when using remote monitoring and management which could, again, compromise security. See The Java SE Monitoring and Management Guide \[[JMXG 2006|AA. Bibliography#JMXG 06]\] for further details and for avoidance strategies.

It is conceivable that both password authentication and SSL might be disabled during development and debugging. If this configuration were carried forward to a production environment, there would be no security in place to prevent an attacker from monitoring and controlling the deployed applicationIf exploited, the monitoring and management facilities can seriously compromise the security of Java applications. For example, an attacker can obtain information about the number of classes loaded and threads running, thread state along with traces of live threads, system properties, VM arguments, and memory consumption.

Noncompliant Code Example (JVMTI)

...

...