...
This guideline is an instance of SEC03-J. Do not load trusted classes after allowing untrusted code to load arbitrary classes. Many examples also violate SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary.
Noncompliant Code Example
...
In this noncompliant code example a call to System.loadLibrary() is embedded in a doPrivileged block. This is insecure because a library can be loaded on behalf of untrusted code. In essence, the untrusted code's class loader may be able to indirectly load a library even though it lacks sufficient permissions to do so directly. After loading the library, untrusted code can call native methods from the library if those methods are accessible. This is possible because the doPrivileged block stops security manager checks being applied to callers further up the execution chain.
| Code Block |
|---|
|
public void load(String libName) {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
System.loadLibrary(libName);
return null;
}
});
}
|
Nonnative library code can also be susceptible to related security flaws. Loading a nonnative safe library may not directly expose a vulnerability. However, after loading an additional unsafe library, an attacker can easily exploit the safe library if it contains other vulnerabilities. Moreover, nonnative libraries often use doPrivileged blocks, making them attractive targets.
Compliant Solution
This compliant solution hard-codes the name of the library to prevent the possibility of tainted values. It also reduces the accessibility of method load() from public to private. Consequently, untrusted callers are prohibited from loading the awt library.
| Code Block |
|---|
|
private void load() {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
System.loadLibrary("awt");
return null;
}
});
}
|
Noncompliant Code Example
A method that passes untrusted inputs to the Class.forName() method might permit an attacker to access classes with escalated privileges. The single argument Class.forName() method is another API method that uses its immediate caller's class loader to load a requested class. Untrusted code can misuse this API to indirectly manufacture classes that have the same privileges as those of the attacker's immediate caller.
| Code Block |
|---|
|
public Class loadClass(String className) {
// className may be the name of a privileged or even a malicious class
return Class.forName(className);
}
|
Compliant Solution
This compliant solution hard-codes the class's name.
| Code Block |
|---|
|
public Class loadClass() {
return Class.forName("Foo");
}
|
Noncompliant Code Example
This noncompliant code example returns an instance of java.sql.Connection from trusted to untrusted code. Untrusted code that lacks the permissions required to create a SQL connection can bypass these restrictions by using the acquired instance directly.
| Code Block |
|---|
|
public Connection getConnection(String url, String username, String password) {
// ...
return DriverManager.getConnection(url, username, password);
}
|
Compliant Solution
The getConnection() method is unsafe because it uses the url to indicate a class to be loaded; this class serves as the database driver. This compliant solution prevents a malicious user from supplying their own URL to the database connection; thereby limiting their ability to load untrusted drivers.
| Code Block |
|---|
|
private String url = // hardwired value
public Connection getConnection(String username, String password) {
// ...
return DriverManager.getConnection(this.url, username, password);
}
|
Noncompliant Code Example (CVE-2013-0422)
Java 1.7.0u10 was exploited in January 2013 because of several vulnerabilities. One vulnerability in the MBeanInstantiator class granted unprivileged code the ability to access any class regardless of the current security policy or accessibility rules. The MBeanInstantiator.findClass() method could be invoked with any string and would attempt to return a Class object. This method delegated its work to the loadClass() method, whose source code is shown:
| Code Block |
|---|
|
/**
* Load a class with the specified loader, or with this object
* class loader if the specified loader is null.
**/
static Class<?> loadClass(String className, ClassLoader loader)
throws ReflectionException {
Class<?> theClass;
if (className == null) {
throw new RuntimeOperationsException(new
IllegalArgumentException("The class name cannot be null"),
"Exception occurred during object instantiation");
}
try {
if (loader == null)
|
Java 1.7.0u10 was exploited in January 2013 because of several vulnerabilities. One vulnerability in the MBeanInstantiator class granted unprivileged code the ability to access any class regardless of the current security policy or accessibility rules. The MBeanInstantiator.findClass() method could be invoked with any string and would attempt to return a Class object. This method delegated its work to the loadClass() method, whose source code is shown:
| Code Block |
|---|
|
/**
* Load a class with the specified loader, or with this object
* class loader if the specified loader is null.
**/
static Class<?> loadClass(String className, ClassLoader loader)
throws ReflectionException {
Class<?> theClass;
if (className == null) {
throw new RuntimeOperationsException(new
IllegalArgumentException("The class name cannot be null"),
"Exception occurred during object instantiation");
}
try {
if (loader == null)
loader = MBeanInstantiator.class.getClassLoader();
if (loader != null) {
theClass = Class.forName(className, false, loader);
} else {
theClass = Class.forName(className);
}
} catch (ClassNotFoundException e) {
throw new ReflectionException(e,
"The MBean class could not be loaded");
}
return theClass;
}
|
This method delegates the task of dynamically loading the specified class to the Class.forName() method. The forName() method delegates the work of loading the class to its calling method's class loader. Since the calling method was MBeanInstantiator.loadClass(), the core class loader is used, which provides no security checks.
Compliant Solution (CVE-2013-0422)
Oracle mitigated this vulnerability in Java 1.7.0p11 by adding an access check to the loadClass() method. This access check ensures that the caller is permitted to access the class being sought:
| Code Block |
|---|
|
// ...
if (className == null) {
throw new RuntimeOperationsException(new
IllegalArgumentException("The class name cannot be null"),
"Exception occurred during object instantiation");
}
ReflectUtil.checkPackageAccess(className);
try {
if (loader == null)
// ...
|
Noncompliant Code Example (CERT Vul# 636312)
CERT Vulnerability 636312 describes a vulnerability in Java that was successfully exploited in August 2012. (The exploit actually used two vulnerabilities; the other one is described in SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields.
A security-sensitive class loader typically employs the security manager to enforce a security policy before loading new classes. For example, the applet class loader ensures that an applet cannot directly invoke methods of classes present in the com.sun.* package. A security manager check ensures that specific actions are allowed or denied depending on the privileges of all of the caller methods on the call stack (the privileges are associated with the code source that encompasses the class). A security manager complements, rather than superseding, the security offered by the class loader architecture. Consequently, APIs that perform security manager checks may still violate this guideline at the class loader level when exposed to untrusted callers.
The goal of the exploit code was to access the private sun.awt.SunToolkit class. However, as the attack code runs in an applet, accessing it directly, using class.forName() would cause a SecurityException to be thrown. Consequently, the exploit code contains the following method to get a class, bypassing its security manager:
| Code Block |
|---|
|
private Class GetClass(String paramString)
throws Throwable
{
Object arrayOfObject[] = new Object[1];
arrayOfObject[0] = paramString;
Expression localExpression = new Expression(Class.class, "forName", arrayOfObject);
localExpression.execute();
return (Class)localExpression.getValue();
}
|
The {[java.beans.Expression.execute()}} method delegates its work to the following method:
| Code Block |
|---|
|
private Object invokeInternal() throws Exception {
Object target = getTarget();
String methodName = getMethodName();
if (target == null || methodName == null) {
throw new NullPointerException((target == null ? "target" :
loader = MBeanInstantiator.class.getClassLoader();
if (loader != null) {
"methodName") + " should not be null"theClass = Class.forName(className, false, loader);
}
Object[] arguments = getArguments();
} ifelse (arguments{
== null) {
arguments = emptyArray;
}
theClass //= Class.forName(className);
won't load classes outside }
// of core} fromcatch a(ClassNotFoundException classe) inside{
core. Special
// case this method.
throw ifnew ReflectionException(targete,
== Class.class && methodName.equals("forName")) {
"The return ClassFinder.resolveClass((String)arguments[0], this.loaderMBean class could not be loaded");
}
// ...
|
The com.sun.beans.finder.ClassFinder.resolveClass() method delegates its work to the findClass() method:
| Code Block |
|---|
|
public static Class<?> findClass(String name) throws ClassNotFoundException {
try {
ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader = ClassLoader.getSystemClassLoader();
}
if (loader != null) {
return Class.forName(name, false, loader);
}
} catch (ClassNotFoundException exception) {
// use current class loader instead
} catch (SecurityException exception) {
// use current class loader instead
}
return Class.forName(name);
}
|
While this method is called in the context of an applet, it uses Class.forName() to obtain the requested class. And Class.forName() delegates the search to the calling method's class loader. In this case the calling class (com.sun.beans.finder.ClassFinder) is part of core Java, so the trusting class loader is used, instead of the more paranoid applet class loader.
Compliant Solution (CVE-2012-4681)
Oracle mitigated this vulnerability by patching the com.sun.beans.finder.ClassFinder.findClass() method. The checkPackageAccess() method checks the entire call stack to ensure that Class.forName() in this instance only fetches classes for trusted methods.
This method delegates the task of dynamically loading the specified class to the Class.forName() method. The forName() method delegates the work of loading the class to its calling method's class loader. Since the calling method was MBeanInstantiator.loadClass(), the core class loader is used, which provides no security checks.
Compliant Solution (CVE-2013-0422)
Oracle mitigated this vulnerability in Java 1.7.0p11 by adding an access check to the loadClass() method. This access check ensures that the caller is permitted to access the class being sought:
| Code Block |
|---|
|
// ...
if (className == null) {
throw new RuntimeOperationsException(new
IllegalArgumentException("The class name cannot be null"),
"Exception occurred during object instantiation");
}
ReflectUtil.checkPackageAccess(className);
try {
if (loader == null)
// ...
|
Noncompliant Code Example (CERT Vul# 636312)
CERT Vulnerability 636312 describes a vulnerability in Java that was successfully exploited in August 2012. (The exploit actually used two vulnerabilities; the other one is described in SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields.
The exploit runs as an applet. The applet class loader ensures that an applet cannot directly invoke methods of classes present in the com.sun.* package. A security manager check ensures that specific actions are allowed or denied depending on the privileges of all of the caller methods on the call stack (the privileges are associated with the code source that encompasses the class).
One goal of the exploit code was to access the private sun.awt.SunToolkit class. However, invoking class.forName() directly would cause a SecurityException to be thrown. Consequently, the exploit code contains the following method to get any class, bypassing the security manager:
| Code Block |
|---|
|
private Class GetClass(String paramString)
throws Throwable
{
Object arrayOfObject[] = new Object[1];
arrayOfObject[0] = paramString;
Expression localExpression = new Expression(Class.class, "forName", arrayOfObject);
localExpression.execute();
return (Class)localExpression.getValue();
}
|
The {[java.beans.Expression.execute()}} method delegates its work to the following method:
| Code Block |
|---|
|
private Object invokeInternal() throws Exception {
Object target = getTarget();
String methodName = getMethodName();
if (target == null || methodName == null) {
throw new NullPointerException((target == null ? "target" :
"methodName") + " should not be null");
}
Object[] arguments = getArguments();
if (arguments |
| Code Block |
|---|
|
public static Class<?> findClass(String name) throws ClassNotFoundException {
checkPackageAccess(name);
try {
ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader == null) {
arguments = //emptyArray;
can be}
null in IE (see 6204697)
loader = ClassLoader.getSystemClassLoader();
}
if (loader != null) {
return Class.forName(name, false, loader);
}
} catch (ClassNotFoundException exception// Class.forName() won't load classes outside
// of core from a class inside core. Special
// case this method.
if (target == Class.class && methodName.equals("forName")) {
// use current class loader insteadreturn ClassFinder.resolveClass((String)arguments[0], this.loader);
} catch (SecurityException exception) {
// use current class loader instead
}
return Class.forName(name);
}
|
Noncompliant Code Example
In this noncompliant code example a call to System.loadLibrary() is embedded in a doPrivileged block. This is insecure because a library can be loaded on behalf of untrusted code. In essence, the untrusted code's class loader may be able to indirectly load a library even though it lacks sufficient permissions to do so directly. After loading the library, untrusted code can call native methods from the library if those methods are accessible. This is possible because the doPrivileged block stops security manager checks being applied to callers further up the execution chain.
| Code Block |
|---|
|
public void load(String libName) {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
System.loadLibrary(libName);
return null;
}
});
}
|
Nonnative library code can also be susceptible to related security flaws. Loading a nonnative safe library may not directly expose a vulnerability. However, after loading an additional unsafe library, an attacker can easily exploit the safe library if it contains other vulnerabilities. Moreover, nonnative libraries often use doPrivileged blocks, making them attractive targets.
Compliant Solution
This compliant solution hard-codes the name of the library to prevent the possibility of tainted values. It also reduces the accessibility of method load() from public to private. Consequently, untrusted callers are prohibited from loading the awt library.
| Code Block |
|---|
|
private void load() {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
System.loadLibrary("awt");
return null;
}
});
}
|
Noncompliant Code Example
A method that passes untrusted inputs to the Class.forName() method might permit an attacker to access classes with escalated privileges. The single argument Class.forName() method is another API method that uses its immediate caller's class loader to load a requested class. Untrusted code can misuse this API to indirectly manufacture classes that have the same privileges as those of the attacker's immediate caller.
| Code Block |
|---|
|
public Class loadClass(String className) {
// className may be the name of a privileged or even a malicious class
return Class.forName(className);
}
|
Compliant Solution
This compliant solution hard-codes the class's name.
| Code Block |
|---|
|
public Class loadClass() {
return Class.forName("Foo");
}
|
Noncompliant Code Example
This noncompliant code example returns an instance of java.sql.Connection from trusted to untrusted code. Untrusted code that lacks the permissions required to create a SQL connection can bypass these restrictions by using the acquired instance directly.
| Code Block |
|---|
|
public Connection getConnection(String url, String username, String password) {
// ...
return DriverManager.getConnection(url, username, password);
}
|
Compliant Solution
The getConnection() method is unsafe because it uses the url to indicate a class to be loaded; this class serves as the database driver. This compliant solution prevents a malicious user from supplying their own URL to the database connection; thereby limiting their ability to load untrusted drivers.
The com.sun.beans.finder.ClassFinder.resolveClass() method delegates its work to the findClass() method:
| Code Block |
|---|
|
public static Class<?> findClass(String name) throws ClassNotFoundException {
try {
ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader = ClassLoader.getSystemClassLoader();
}
if (loader != null) {
return Class.forName(name, false, loader);
}
} catch (ClassNotFoundException exception) {
// use current class loader instead
} catch (SecurityException exception) {
// use current class loader instead
}
return Class.forName(name);
}
|
While this method is called in the context of an applet, it uses Class.forName() to obtain the requested class. And Class.forName() delegates the search to the calling method's class loader. In this case the calling class (com.sun.beans.finder.ClassFinder) is part of core Java, so the trusting class loader is used, instead of the more paranoid applet class loader.
Compliant Solution (CVE-2012-4681)
Oracle mitigated this vulnerability by patching the com.sun.beans.finder.ClassFinder.findClass() method. The checkPackageAccess() method checks the entire call stack to ensure that Class.forName() in this instance only fetches classes for trusted methods.
| Code Block |
|---|
|
public static Class<?> findClass(String name) throws ClassNotFoundException {
checkPackageAccess(name);
try {
ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader == null) {
// can be null in IE (see 6204697)
loader = ClassLoader.getSystemClassLoader();
}
if (loader != null) {
return Class.forName(name, false, loader);
}
} catch (ClassNotFoundException exception) {
// use current class loader instead
} catch (SecurityException exception) {
// use current class loader instead
}
return Class.forName(name);
} |
| Code Block |
|---|
|
private String url = // hardwired value
public Connection getConnection(String username, String password) {
// ...
return DriverManager.getConnection(this.url, username, password);
}
|
Applicability
Allowing untrusted code to invoke methods with reduced security checks can grant excessive abilities to malicious code. Likewise, allowing untrusted code to carry out actions using the immediate caller's class loader may allow the untrusted code to execute with the same privileges as the immediate caller.
...
