Page History

...

A method which receives an untrusted, non-final input argument must beware that other methods or threads might modify the input object. Some methods attempt to prevent modification by making a local copy of the input object. This is insufficient, because a shallow copy of an object may still allow it to refer to mutable sub-objects, which may still be modified by other methods or threads. Some methods go farther and perform a deep copy of the input object. This mitigates the problem of modifiable sub-objects, but the method might still receive as an argument a mutable object that extends the input object class.

Noncompliant Code Example (BigInteger)

This noncompliant code example uses the immutable java.math.BigInteger class.

...

This malicious BigInteger class is clearly mutable, because of the setValue() method. Furthermore, the modPow() method is subject to precision loss (see NUM00-J. Detect or prevent integer overflow, NUM11-J. Check floating point inputs for exceptional values, NUM15-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data and NUM17-J. Beware of precision loss when converting primitive integers to floating-point for more information). Any code that receives an object of this class, and assumes that the object is immutable will have unexpected behavior. This is particularly important because the BigInteger.modPow() method has several useful cryptographic applications.

Noncompliant Code Example (Security Manager)

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 2007|AA. Bibliography#SCG 07]\]. It also compares class types, in compliance with [OBJ06-J. Compare classes and not class names].

...

Unfortunately, throwing an exception from the constructor of a non-final class is insecure because it allows a finalizer attack (see OBJ04-J. Do not allow access to partially initialized objects).

Compliant Solution (final)

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.

final class BigInteger {
  // ...
}

Compliant Solution (Class Sanitization)

When instances of non-final classes are obtained from untrusted sources, such instances must be used with care, because their method calls 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|AA. Bibliography#Bloch 08]\].

...

The guidelines FIO00-J. Defensively copy mutable inputs and mutable internal components and OBJ10-J. Provide mutable classes with copy functionality to allow passing instances to untrusted code safely discuss defensive copying in great depth.

Compliant Solution (Java SE 6, public and private constructors)

This compliant solution invokes a security manager check as a side-effect of computing the boolean value passed to a private constructor (as seen in guideline OBJ04-J. Do not allow access to partially initialized objects). The rules for order of evaluation require that the security manager check must execute before invocation of the private constructor. Consequently, the security manager check also executes before invocation of any superclass's constructor. Note that the security manager check is made without regard to whether the object under construction has the type of the parent class or the type of a subclass (whether trusted or not).

...

public class BigInteger {
  public BigInteger(String str) {
    this( str, check( this.getClass())); // throws a security exception if not allowed
  }
  
  private BigInteger(String str, boolean securityManagerCheck) {
    // regular construction goes here
  }

  private static boolean check(Class c) {
    // Confirm class type
    if (c != BigInteger.class) {
      // Check the permission needed to subclass BigInteger
      securityManagerCheck(); // throws a security exception if not allowed
    }

    return true;
  }
}

Risk Assessment

Permitting a non-final class or method to be inherited without checking the class instance allows a malicious subclass to misuse the privileges of the class.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

\[[API 2006|AA. Bibliography#API 06]\] Class BigInteger
\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 1: "Consider static factory methods instead of constructors"
\[[Gong 2003|AA. Bibliography#Gong 03]\] Chapter 6: "Enforcing Security Policy"
\[[Lai 2008|AA. Bibliography#Lai 08]\]
\[[McGraw 2000|AA. Bibliography#McGraw 00]\] Chapter Seven Rule 3: "Make Everything Final, Unless There's a Good Reason Not To"\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 1-2 "Limit the extensibility of classes and methods"
\[[SCG 2009|AA. Bibliography#SCG 09]\]

...