Page History

In the presence of a security manager , it is hard for malicious code to exploit Java's security modeland a restrictive system-wide security policy, untrusted code is prohibited from performing privileged operations. For example, instantiating instantiation of sensitive classes such as java.lang.ClassLoader is prohibited in the context of a web browser. It At the same time, it is critical to ensure that untrusted code does not indirectly use the privileges of legit trusted code that is allowed to instantiate and use sensitive classes. Failure to do so can leave the code vulnerable to privilege escalation attacks. This is because, classes loaded by the same class loader exist in the same namespace and have identical privileges. Consider for example, an untrusted method calling a class method which loads classes using its own trusted class loader. This is a problem as untrusted code's class loader may not have the permission to load the particular class. Also, if the trusted code accepts tainted inputs, malicious classes may be loaded. The APIs tabulated below perform tasks using the immediate caller's class loader. They can be exploited if (1) They are invoked indirectly by untrusted code and/or (2) They accept tainted inputs from untrusted codeto perform privileged operations. Most APIs install security manager checks to prevent this, however, some do not. These APIs are tabulated below.

These APIs perform tasks using the immediate caller's class loader. They can be exploited if (1) They are invoked indirectly by untrusted code and/or (2) They accept tainted inputs from untrusted code.

Classes that have the same defining class loader exist in the same namespace but may have different privileges, depending on the security policy. Security vulnerabilities can arise if the trusted code coexists with untrusted code, and both have the same defining class loader. This is because untrusted code can freely access members of the trusted code depending on their accessibility. If the trusted code uses any of the tabulated APIs, no security manager checks are carried out.

Sometimes untrusted code is loaded by a class loader instance that is different from the one used to load the trusted code. Security vulnerabilities can arise if the untrusted code's class loader delegates to the trusted code's class loader. In the absence of such a delegation relationship, the class loaders ensure namespace separation and disallow untrusted code from observing members or invoking methods belonging to the trusted code.

Consider for example, untrusted code that is attempting to load a privileged class. Its class loader is permitted to delegate the class loading to the trusted class's class loader. This is a problem as untrusted code's class loader may not have the permission to load the particular class. Also, if the trusted code accepts tainted inputs, malicious classes may be loaded on behalf of untrusted code.

Noncompliant Code Example

...

Non-native library code can also be susceptible to related security flaws. Loading a non-native safe library, by itself may not expose a vulnerability but after loading an unsafe library, an attacker can easily exploit it if it contains other vulnerabilities. Moreover, non-native libraries often use doPrivileged blocks, making them a lucrative targettargets.

Compliant Solution

Ensure that untrusted code cannot invoke the affected APIs directly or indirectly (that is, via a call to an invoking method). In this case, the loadLib() method must be declared private so that it is only available to a more restrictive method within the class. The restrictive method can ensure that the caller has sufficient permissions to load the library.

...

// className is Foo may be the name of a privileged or even a malicious class
Class c = Class.forName(className);

...

Ensure that instances of objects created using the vulnerable unsafe methods are not returned to untrusted code. Furthermore, it is preferable to reduce the accessibility of methods that perform sensitive operations and define wrapper methods that are accessible from untrusted code.

...