Page History

In the presence of a security manager and a restrictive system-wide security policy, untrusted code is prohibited Java uses security managers and security policies together to prevent untrusted code from performing privileged operations. For example, In standard installations, a restrictive system-wide security policy prevents instantiation of sensitive classes such as java.lang.ClassLoader is prohibited in the context of a web browser. At the same time, it is critical , for example. It remains critically important to ensure that untrusted code does not cannot indirectly use the privileges of trusted code to perform privileged operations.

Most APIs install security manager checks to prevent this, however, some do notsuch privilege escalation attacks; some APIs fail to do so. These APIs are tabulated below. Note, with the exception of the loadLibrary and load APIs. The however, that the loadLibrary and load APIs throw a security exception if when the caller does not have permissions lacks permission to dynamically link the library code. However, they These APIs are nevertheless listed as unsafe because they use the immediate caller's class loader to find and load the requested library. Moreover, because the loadLibrary and load APIs are typically used from within a doPrivileged block defined in trusted code, untrusted callers can directly invoke it, without requiring any special permissions.

...

These APIs perform tasks using the immediate caller's class loader. They can be exploited if when (1) They they are invoked indirectly by untrusted code and/or (2) They 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 when trusted code coexists with untrusted code , and both have that was loaded by the same defining class loader. This is because In this case, the untrusted code can freely access members of the trusted code depending on according to their declared accessibility. If When the trusted code uses any of the tabulated APIs, no security manager checks are carried out (with the exception of loadLibrary and load).

Sometimes Security vulnerabilities can also arise even when untrusted code is has been loaded by a class loader instance that is different distinct from the one class loader used to load the trusted code. Security vulnerabilities can arise if When the untrusted code's class loader delegates to the trusted code's class loader, the untrusted code has visibility to the trusted code according to the declared visibility of the trusted code. In the absence of such a delegation relationship, the class loaders would ensure namespace separation and disallow ; consequently the untrusted code from observing would be unable to observe members or invoking to invoke 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 can result in privilege escalation, because the untrusted code's class loader may not have the lack permission to load the particular requested privileged class. AlsoFurther, if the trusted code accepts tainted inputs, more privileged the trusted code's class loader could load additional privileged — or even malicious — classes may be loaded on behalf of the untrusted code.

Noncompliant Code Example

The In this noncompliant code example, the untrustedCode() method of class Untrusted invokes the loadLib() method of class NativeCode in this noncompliant code example. This is insecure as because the library is loaded on behalf of untrusted code. In essence, the untrusted code's class loader may be able to indirectly load the intended library even if though it does not have lacks sufficient permissions. After loading the library, untrusted code can call native methods on it if the methods are accessible.

...

Noncompliant Code Example

Sometimes, In this noncompliant code example a call to System.loadLibrary() is embedded in a doPrivileged block, as shown below. An unprivileged caller can maliciously invoke this piece of code using the same technique as above, because the doPrivileged block allows security manager checks to be forgone for other callers on the execution chain.

...

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

...

Accepting tainted inputs from untrusted code can further exacerbate the issuepermit an attacker to load classes with escalated privileges. The single argument Class.forName() method is another example of an API method that uses its immediate caller's class loader to load a desired requested class. Untrusted code can indirectly misuse this API to indirectly manufacture classes with that have the same privileges as those of the attacker's immediate caller.

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

...

This noncompliant code example returns an instance of java.sql.Connection from trusted to untrusted code. The untrusted Untrusted code that does not have lacks the permissions required to create an SQL connection can bypass this restriction these restrictions by directly using the acquired instance directly.

public Connection getConnection() {
  // ...
  return DriverManager.getConnection(url, username, password);
}

...

Allowing untrusted code to carry out actions using the immediate caller's class loader may allow it the untrusted code to execute with the same privileges as the immediate caller.

...