Page History

...

JVM Tool Interface (JVMTI)

TheJava 5 introduced the JVM Tool Interface (JVMTI) \[[JVMTISun 200604d|AA. Bibliography#JVMTIBibliography#Sun 0604d]\], provides facilities for queryingreplacing both the internalsJVM ofProfiler aInterface JVM(JVMPI) and includesthe methodsJVM forDebug 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. Interface (JVMDI), which are now deprecated.

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 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) \[[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.

...

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.

...

The JVM Tool 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.

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 with no security for their own purposes, and this would leave the JVM open to compromise 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:

...

...