Most methods perform no security manager checks because they do not provide access to sensitive parts of the system, such as the filesystem. Most methods that do provide security manager checks check that every class and method in the call stack is authorized before they proceed. This allows restricted programs, such as Java applets, to have full access to the core Java library. This security model prevents a sensitive method from acting on behalf of a malicious method that hides behind a trusted method in the call stack.
However, certain methods use a reduced security check, that only checks that the calling method has access, rather then checking every method in the call stack. Code that invokes these methods must guarentee that they are not being invoked on behalf of untrusted code. These methods are:
APIs that mirror language checks |
|---|
Class loaders allow a Java application to be dynamically extended at runtime by loading classes. For each class that is loaded, the JVM tracks the class loader that was used to load the class. When a loaded class first refers to another class, the virtual machine requests that the referenced class be loaded by the same class loader used to load the referencing class.
Java's class loader architecture controls interaction between code loaded from different sources by allowing the use of different class loaders. This separation of class loaders is fundamental to the separation of code; it prevents malicious code from gaining access to and subverting trusted code. A class loader that loads untrusted code must be prevented from interacting with trusted code that invokes any of the methods from the following table:
| Methods | |||
|---|---|---|---|
| |||
| |||
| Package.getPackages
| ||
| |||
| |||
| |||
| |||
| sql
| DriverManager
| getDrivers
|
|
In practice, the trusted code's class loader frequently allows these methods to be invoked whereas untrusted code's class loader may lack these privileges. However, when the untrusted code's class loader delegates to the trusted code's class loader, the untrusted code gains visibility to the trusted code. In the absence of such a delegation relationship, the class loaders would ensure namespace separation; consequently, the untrusted code would be unable to observe members or to invoke methods belonging to the trusted code.
A problem arises because the class loader delegation model is fundamental to many Java implementations and frameworks. So the best advice is to avoid exposing the methods listed above to untrusted code.
Consider, for example, an attack scenario where untrusted code is attempting to load a privileged class. If its class loader is permitted to delegate the class loading to a trusted class's class loader, privilege escalation can occur, because the untrusted code's class loader may lack permission to load the requested privileged class on its own. Furthermore, if the trusted code accepts tainted inputs, the trusted code's class loader could load additional privileged — or even malicious — classes on behalf of the untrusted code.
Classes that have the same defining class loader will exist in the same namespace but can have different privileges, depending on the security policy. Security vulnerabilities can arise when trusted code coexists with untrusted code (or less-privileged code) that was loaded by the same class loader. In this case, the untrusted (or less-privileged) code can freely access members of the trusted code according to their declared accessibility. When the trusted code uses any of the tabulated APIs, it bypasses security manager checks (with the exception of loadLibrary() and load()).
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.
With the exception of the loadLibrary() and load() methods, the tabulated methods fail to perform any security manager checks. The loadLibrary() and load() APIs are typically used from within a doPrivileged block; in that case, unprivileged callers can directly invoke them without requiring any special permissions. Consequently, the security manager checks are curtailed at the immediate caller. The security manager fails to examine the entire call stack and so fails to enhance security. Accepting tainted inputs from untrusted code and allowing them to be used by these APIs may expose vulnerabilities.
The following lists the APIs that should be used with care.
...
APIs that mirror language checks
...
java.lang.Class.newInstance
...
java.lang.reflect.Constructor.newInstance
...
java.lang.reflect.Field.get*
...
java.lang.reflect.Field.set*
...
java.lang.reflect.Method.invoke
...
java.util.concurrent.atomic.AtomicIntegerFieldUpdater.newUpdater
...
java.util.concurrent.atomic.AtomicLongFieldUpdater.newUpdater
|
Class loaders allow a Java application to be dynamically extended at runtime by loading classes. For each class that is loaded, the JVM tracks the class loader that was used to load the class. When a loaded class first refers to another class, the virtual machine requests that the referenced class be loaded by the same class loader used to load the referencing class. Java's class loader architecture controls interaction between code loaded from different sources by allowing the use of different class loaders. This separation of class loaders is fundamental to the separation of code; it prevents malicious code from gaining access to and subverting trusted code.
Several methods, that are charged with loading classes, delegate their work to the class loader of the class of the method that called them. The security checks associated with loading classes is often performed by class loaders. Consequently, any method that invokes one of these class-loading methods must guarentee that these methods are not acting on behalf of untrusted code. These methods are:
Methods |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
The reflection APIs permit an object to access fields and methods of another object by name rather than by reference. The Java Virtual Machine (JVM) enforces policy compliance during such accesses by performing language access checks. For instance, although an object is not normally allowed to access private members or invoke methods of another class, the APIs belonging to the java.lang.reflectpackage allow an object to do so contingent upon performing the language-defined access checks. It is important to note, however, that these access checks consider only the language-level visibility of the immediate caller. Consequently, unwary programmers can afford an opportunity for a privilege escalation attack by untrusted callers.
Because the java.lang.reflect.Field.setAccessible/getAccessible methods are used to instruct the JVM to override the language access checks, they perform standard (and more restrictive) security manager checks and consequently lack the vulnerability discussed in this guideline. Nevertheless, these methods should be used only with extreme caution. The remaining set* and get* field reflection methods perform only the language access checks and consequently are vulnerable.
Use of reflection complicates security analysis and can introduce substantial security vulnerabilities. Consequently, programmers should avoid the use of the reflection APIs when it is feasible to do so. When use of reflection is necessary, exercise extreme caution.
In practice, the trusted code's class loader frequently allows these methods to be invoked whereas untrusted code's class loader may lack these privileges. However, when the untrusted code's class loader delegates to the trusted code's class loader, the untrusted code gains visibility to the trusted code. In the absence of such a delegation relationship, the class loaders would ensure namespace separation; consequently, the untrusted code would be unable to observe members or to invoke methods belonging to the trusted code.
A problem arises because the class loader delegation model is fundamental to many Java implementations and frameworks. So the best advice is to avoid exposing the methods listed above to untrusted code.
Consider, for example, an attack scenario where untrusted code is attempting to load a privileged class. If its class loader is permitted to delegate the class loading to a trusted class's class loader, privilege escalation can occur, because the untrusted code's class loader may lack permission to load the requested privileged class on its own. Furthermore, if the trusted code accepts tainted inputs, the trusted code's class loader could load additional privileged — or even malicious — classes on behalf of the untrusted code.
Classes that have the same defining class loader will exist in the same namespace but can have different privileges, depending on the security policy. Security vulnerabilities can arise when trusted code coexists with untrusted code (or less-privileged code) that was loaded by the same class loader. In this case, the untrusted (or less-privileged) code can freely access members of the trusted code according to their declared accessibility. When the trusted code uses any of the tabulated APIs, it bypasses security manager checks (with the exception of loadLibrary() and load()).
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.
With the exception of the loadLibrary() and load() methods, the tabulated methods fail to perform any security manager checks. The loadLibrary() and load() APIs are typically used from within a doPrivileged block; in that case, unprivileged callers can directly invoke them without requiring any special permissions. Consequently, the security manager checks are curtailed at the immediate caller. The security manager fails to examine the entire call stack and so fails to enhance security. Accepting tainted inputs from untrusted code and allowing them to be used by these APIs may expose vulnerabilities.
The following lists the APIs that only check the immediate caller's class for security.
...
Because the java.lang.reflect.Field.setAccessible/getAccessible methods are used to instruct the JVM to override the language access checks, they perform standard (and more restrictive) security manager checks and consequently lack the vulnerability discussed in this guideline. Nevertheless, these methods should be used only with extreme caution. The remaining set* and get* field reflection methods perform only the language access checks and consequently are vulnerable.
...
Related Guidelines
| [SCG 2010] | |
| [SCG 2010] | Guideline 9-10: Be aware of standard APIs that perform Java language access checks against the immediate caller |
Bibliography
...