...
The following code example demonstrates such an attack.
Code Block | ||
---|---|---|
| ||
BigInteger msg = new BigInteger("123");
msg = msg.modPow(exp, m); // Always returns 1
// Malicious subclassing of java.math.BigInteger
class BigInteger extends java.math.BigInteger {
private int value;
public BigInteger(String str) {
super(str);
value = Integer.parseInt(str);
}
public void setValue(int value) {
this.value = value;
}
@Override public java.math.BigInteger modPow(
java.math.BigInteger exponent, java.math.BigInteger m) {
this.value = ((int) (Math.pow(this.doubleValue(),
exponent.doubleValue()))) % m.intValue();
return this;
}
}
|
...
This noncompliant code example installs a security manager check in the constructor of the BigInteger
class. The security manager denies access when it detects that a subclass without the requisite permissions is attempting to instantiate the superclass [SCG 2009]. It also compares class types, in compliance with rule OBJ09-J. Compare classes and not class names. Note that this check does not prevent malicious extensions of BigInteger
, it instead prevents the creation of BigInteger
objects from untrusted code, which also prevents creation of objects of malicious extensions of BigInteger
.
Code Block | ||
---|---|---|
| ||
public class BigInteger {
public BigInteger(String str) {
securityManagerCheck();
// ...
}
// Check the permission needed to subclass BigInteger
// throws a security exception if not allowed
private void securityManagerCheck() {
// ...
}
}
|
...
This compliant solution prevents creation of malicious subclasses by declaring the immutable BigInteger
class to be final. Although this solution would be appropriate for locally maintained code, it cannot be used in the case of java.math.BigInteger
because it would require changing the Java SE API, which has already been published and must remain compatible with previous versions.
Code Block | ||
---|---|---|
| ||
final class BigInteger {
// ...
}
|
...
The instances of nonfinal classes obtained from untrusted sources must be used with care because their methods might be overridden by malicious methods. This potential vulnerability can be mitigated by making defensive copies of the acquired instances prior to use. This compliant solution demonstrates this technique for a BigInteger
argument [Bloch 2008].
Code Block | ||
---|---|---|
| ||
public static BigInteger safeInstance(BigInteger val) {
// create a defensive copy if it is not java.math.BigInteger
if (val.getClass() != java.math.BigInteger.class) {
return new BigInteger(val.toByteArray());
}
return val;
}
|
...
This solution prevents the finalizer attack; it applies to Java SE 6 and later versions, where throwing an exception before the java.lang.Object
constructor exits prevents execution of finalizers [SCG 2009].
Code Block | ||
---|---|---|
| ||
public class BigInteger {
public BigInteger(String str) {
this(str, check());
}
private BigInteger(String str, boolean dummy) {
// regular construction goes here
}
private static boolean check() {
securityManagerCheck();
return true;
}
}
|
...
This noncompliant code example invokes an overridable getMethodName()
method in the privileged block using the reflection mechanism.
Code Block | ||
---|---|---|
| ||
public class MethodInvoker {
public void invokeMethod() {
AccessController.doPrivileged(new PrivilegedAction<Object>() {
public Object run() {
try {
Class<?> thisClass = MethodInvoker.class;
String methodName = getMethodName();
Method method = thisClass.getMethod(methodName, null);
method.invoke(new MethodInvoker(), null);
} catch (Throwable t) {
// Forward to handler
}
return null;
}
}
);
}
String getMethodName() {
return "someMethod";
}
public void someMethod() {
// ...
}
// Other methods
}
|
...
This compliant solution declares the getMethodName()
method final so that it cannot be overridden.
Code Block | ||
---|---|---|
| ||
final String getMethodName() {
// ...
}
|
Alternative approaches that prevent overriding of the getMethodName()
method include declaring it as private or declaring the enclosing class as final.
Compliant Solution (Disallow Polymorphism)
This compliant solution specifically invokes the correct getMethodName()
, preventing diversion of control flow.
...
...
public void invokeMethod() {
AccessController.doPrivileged(new PrivilegedAction<Object>() {
public Object run() {
try {
Class<?> thisClass = MethodInvoker.class;
String methodName = MethodInvoker.this.getMethodName();
Method method = thisClass.getMethod(methodName, null);
method.invoke(new MethodInvoker(), null);
} catch (Throwable t) {
// Forward to handler
}
return null;
}
}
);
}
Risk Assessment
Permitting a nonfinal class or method to be inherited without checking the class instance allows a malicious subclass to misuse the privileges of the class.
...
[API 2006] | Class BigInteger |
Item 1. Consider static factory methods instead of constructors | |
Chapter 6, Enforcing Security Policy | |
[Lai 2008] | Java Insecurity, Accounting for Subtleties That Can Compromise Code |
Chapter Seven, Rule 3. Make everything final, unless there's a good reason not to | |
04. Object Orientation (OBJ) 04. Object Orientation (OBJ) OBJ01-J. Declare data members as private and provide accessible wrapper methods