Java Reference
In-Depth Information
code) that was loaded by the same class loader. In this case, the less privileged code can
freely access members of the privileged code according to the privileged code's declared
accessibility. When the privileged code uses any of the tabulated APIs, it bypasses secur-
ity manager checks (with the exception of
loadLibrary()
and
load()
).
This guideline is similar to
The CERT
®
Oracle
®
Secure Coding Standard for Java
™
[Long 2012], “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.
public void load(String libName) {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
System.loadLibrary(libName);
return null;
}
});
}
This code is insecure because it could be used to load a library on behalf of untrusted
code. In essence, the untrusted code's class loader may be able to use this code to load
a library even though it lacks sufficient permissions to do so directly. After loading the
library, the untrusted code can call native methods from the library, if those methods are
accessible, because the
doPrivileged
block prevents any security manager checks from
being applied to callers further up the execution stack.
Nonnative library code can also be susceptible to related security flaws. Suppose there
exists a library that contains a vulnerability that is not directly exposed, perhaps because
it lies in an unused method. Loading this library may not directly expose a vulnerability.
However, an attacker could then load an additional library that exploits the first library's
vulnerability.Moreover,nonnativelibrariesoftenuse
doPrivileged
blocks,makingthem
attractive targets.
