Page History

...

JVM Tool Interface (JVMTI)

Wiki MarkupJava 5 introduced the JVM Tool Interface (JVMTI) \ [[Sun 04d|AA. References#Sun 04d]\], replacing both the JVM Profiler Interface (JVMPI) and the JVM Debug Interface (JVMDI), which are now deprecated.

The JVMTI contains extensive facilities to 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 programming. However, they provide the opportunity to access fields that would normally be inaccessible. 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.

...

Java Platform Debugger Architecture (JPDA)

Wiki MarkupThe 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. References#JPDA 2004]\].

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

...

Java SE Monitoring and Management Features

...

Java contains extensive facilities for monitoring and managing a JVM \ [[JMX 2006|AA. References#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. References#Sun 04a]\]. It also has facilities for logging monitoring and management.

The Java SE monitoring and management features fall into four broad categories:

...

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

Wiki Markup 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. References#JMXG 06]\].].

The JVM remote monitoring and management facility uses a secure communication channel (Secure Sockets Layer SSL) by default. However, if an attacker can start a bogus remote method invocation (RMI) registry server on the monitored machine before the legitimate RMI registry server 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] for further details and for mitigation Wiki MarkupThe JVM remote monitoring and management facility uses a secure communication channel (Secure Sockets Layer [SSL]) by default. However, if an attacker can start a bogus remote method invocation (RMI) registry server on the monitored machine before the legitimate RMI registry server 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. References#JMXG 06]\] for further details and for mitigation strategies.

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; this would leave the JVM open to attack 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.

...

Code Block
bgColor #FFcccc
${JDK_PATH}/bin/java -agentlib:libname=options ApplicationName

Wiki MarkupSome JVMs allow agents to be started when the JVM is already running. This is insecure in a production environment. Refer to the JVMTI documentation \ [[JVMTI 2006|AA. References#JVMTI 06]\] for platform-specific information on enabling/disabling this feature. unmigrated-wiki-markup

Platforms that support environment variables allow agents to be specified in such variables. "Platforms may disable this feature in cases where security is a concern; for example, the Reference Implementation disables this feature on UNIX systems when the effective user or group ID differs from the real ID" \ [[JVMTI 2006|AA. References#JVMTI 06]\].

Agents may run under the default security manager without requiring any permissions to be granted. While the JVMTI is useful for debuggers and profilers, such levels of access are inappropriate for deployed production code.

...

Local monitoring uses temporary files and sets the file permissions to those of the owner of the JVM process. Ensure that adequate file protection is in place on the system running the JVM so that the temporary files are accessed appropriately. See rule FIO03-J. Remove temporary files before termination for additional information.

Wiki MarkupThe _Java SE Monitoring and Management Guide_ \[[JMXG 2006|AA. References#JMXG 06]\] provides further The Java SE Monitoring and Management Guide [JMXG 2006] provides further advice:

Local monitoring with jconsole is useful for development and prototyping. Using jconsole locally is not recommended for production environments because jconsole itself consumes significant system resources. Rather, use jconsole on a remote system to isolate it from the platform being monitored.

...

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

...

      15. Runtime Environment (ENV)      49. Miscellaneous (MSC)