...
Java 5 introduced the JVM Tool Interface (JVMTI) [Sun 04d], replacing both the JVM Profiler Interface (JVMPI) and the JVM Debug Interface (JVMDI), which are now deprecated.
...
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].
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 contains extensive facilities for monitoring and managing a JVM [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]. It also has facilities for logging monitoring and management.
...
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].
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 strategies.
...
Some 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] for platform-specific information on enabling/disabling this feature.
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].
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.
...
The Java SE Monitoring and Management Guide [JMXG 2006] provides further advice:
...
JVMTI is not supported on the Dalvik VM.
Bibliography
[JMX 2006] |
|
| |
| |
| |
Section 2.6, The JVM Tool Interface; Section 2.7, Debugging; Section 2.8, Monitoring and Management | |
Reflection, Sun Microsystems, Inc. (2006) |
...