SecurityManager策略能否提权？三类关键权限的利用疑问

Great question—these three permissions are some of the most dangerous to grant to untrusted code because they effectively punch massive holes in your SecurityManager sandbox. Let’s break down each one’s exploit potential, then cover practical ways to mitigate the risks since you need them for your service:

RuntimePermission("createClassLoader") #

Custom class loaders are a core attack vector because they let untrusted code bypass your SecurityManager’s policy entirely. Here’s how an attacker could exploit this:

• Load unregulated bytecode: A malicious class loader can load arbitrary class files from outside your controlled environment (like the local filesystem or a remote server) that aren’t subject to your policy rules. For example, they could load a class that calls Runtime.exec() to run system commands, even if your policy explicitly blocks that permission.
• Tamper with existing classes: Attackers can use a custom loader to redefine already-loaded system classes (like java.lang.String or java.security.SecurityManager) to alter their behavior—say, stealing sensitive data or disabling the sandbox entirely.
• Escape permission contexts: Class loaders define the security context for the classes they load. A malicious loader could override the default security checks to grant itself full privileges, regardless of your policy.

Mitigation #

• Restrict loader scope: Only allow custom loaders to load classes from a tightly controlled, read-only directory or JAR files you’ve signed and verified.
• Lock down loader implementation: If you’re providing the class loader to untrusted code, make sure it’s a custom, audited implementation that overrides loadClass() to block access to sensitive system classes and validate all incoming bytecode.
• Use a policy that limits loader capabilities: Add additional rules in your security policy to prevent the custom loader from accessing resources it doesn’t need.

RuntimePermission("accessClassInPackage.sun") #

Sun/Oracle’s internal sun.* packages contain low-level, undocumented APIs that were never designed to be exposed to untrusted code. Exploiting this permission usually centers on:

• Using sun.misc.Unsafe: This class is the holy grail for sandbox escapes—it lets attackers directly manipulate memory, allocate objects without constructors, and even execute native code via JNI. With access to Unsafe, an attacker can completely bypass the SecurityManager, modify JVM internal state, or run arbitrary system commands.
• Bypassing security checks: Many sun.* classes have methods that skip standard Java security checks. For example, some internal IO classes can read/write files without triggering SecurityManager permission checks.

Mitigation #

• Avoid granting the entire package: Instead of allowing access to the entire sun package, narrow the permission to only the specific sub-packages or classes your service actually needs (e.g., RuntimePermission("accessClassInPackage.sun.misc") if you must use Unsafe for a specific feature).
• Replace with public APIs: Whenever possible, swap out sun.* usage with standard, documented Java APIs. Most use cases for internal classes have public alternatives now.
• Monitor access: Use a custom SecurityManager or agent to log and block unexpected access to sun.* classes by untrusted code.

ReflectPermission("suppressAccessChecks") #

This permission lets attackers bypass Java’s built-in access control rules, which is a huge risk for sandbox integrity:

• Disable the SecurityManager: Attackers can use reflection to access the private security field in java.lang.System and set it to null, turning off the sandbox entirely.
• Execute restricted methods: They can reflectively invoke private methods in system classes—like Runtime.exec() (even if your policy blocks RuntimePermission("exec")) or methods that modify system properties.
• Tamper with sensitive data: Reflection can be used to read or modify private fields in your service’s classes, stealing credentials or altering application state.

Mitigation #

• Narrow the permission scope: Instead of granting global suppressAccessChecks, use policy rules that only allow reflection on specific classes/methods your service requires (though this can be tricky to configure).
• Block reflection on security-critical classes: Add a custom SecurityManager check to prevent untrusted code from reflecting on java.security.SecurityManager, java.lang.System, or other core security classes.
• Use reflection proxies: Wrap reflective operations in a controlled proxy that validates each call, ensuring untrusted code can only access the specific methods/fields you explicitly allow.

Remember: Even with these mitigations, granting any of these permissions to untrusted code significantly increases your attack surface. Always follow the principle of least privilege—only grant the minimum permissions necessary, and audit all untrusted code thoroughly before execution.

内容的提问来源于stack exchange，提问作者Michal