OBJ11-J. Be wary of letting constructors throw exceptions

An object is partially initialized if a constructor has begun building the object but has not finished. If the object is not fully initialized, it must be hidden from other classes.

Other classes might access a partially-initialized object from concurrently-running threads. This rule is a specific instance of [TSM01-J. Do not let the (this) reference escape during object construction] but focuses only on single-threaded programs. Multithreaded programs must also comply with TSM03-J. Do not publish partially initialized objects.

One of the ways in which a partially-initialized object can become visible to other classes is if the class's constructor throws an exception before initialization is complete. An attacker can maliciously obtain the instance of such an object. For example, an attack that uses the finalizer construct allows an attacker to invoke arbitrary methods within the class, even if the class methods are protected by a security manager.

There are several approaches to ensuring that a class's fields are initialized. Declaring a field to be final ensures that the compiler will produce a warning when there is a possibility that the field could remain uninitialized. This also guarantees initialization safety in multi-threaded code. According to §17.5, "Final Field Semantics" of the Java Language Specification [[JLS 2005]]

An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields.

In other words, when a constructor executing in one thread initializes a final field to a known safe value, other threads are unable to see the pre-initialization value of the object.

Finally, a third approach to dealing with uninitialized objects is to allow the object to exist in a known failed state; such objects are commonly known as "zombie objects." This solution is error-prone because any access to such a class must first check whether or not the object has been correctly initialized.

Some uses of variables require failure atomicity; that is, a variable must not be initialized to null as a result of an object construction failure. This requirement typically arises when a variable constitutes an aggregation of different objects, for example, a composition-and forwarding-based approach, as described in rule OBJ02-J. Preserve dependencies in subclasses when changing superclasses. In the absence of failure atomicity, the variable can be left in an inconsistent state as a result of missing or incorrect initialization.

Noncompliant Code Example (finalizer attack)

This noncompliant code example, based on an example by Kabutz [[Kabutz 2001]], defines the constructor of the BankOperations class so that it performs SSN verification using the method performSSNVerification(). Because we assume that an attacker does not know the correct SSN, the example implementation of the performSSNVerification() method trivially returns false.

public class BankOperations {
  public BankOperations() {
    if (!performSSNVerification()) {
      throw new SecurityException("Invalid SSN!");
    }
  }

  private boolean performSSNVerification() {
    return false; // Returns true if data entered is valid, else false. Assume that the attacker always enters an invalid SSN.
  }

  public void greet() {
    System.out.println("Welcome user! You may now use all the features.");
  }
}

public class UserApp {
  public static void main(String[] args) {
    BankOperations bo;
    try {
      bo = new BankOperations();
    } catch(SecurityException ex) { bo = null; }

    Storage.store(bo);
    System.out.println("Proceed with normal logic");
  }
}

The constructor throws a SecurityException when SSN verification fails. The UserApp class appropriately catches this exception and displays an access denied message. However, these precautions fail to prevent a malicious program from invoking methods of the partially-initialized class BankOperations, as shown by the following exploit code.

public class Storage {
  private static BankOperations bop;

  public static void store(BankOperations bo) {
  // Only store if it is initialized
    if (bop == null) {
      if (bo == null) {
        System.out.println("Invalid object!");
        System.exit(1);
      }
      bop = bo;
    }
  }
}

The goal of the attack is to capture a reference to the partially initialized object of the BankOperation class. If a malicious subclass catches the SecurityException thrown by the BankOperations constructor, it is unable to further exploit the vulnerable code because the new object instance has gone out of scope. Instead, an attacker can exploit this code by extending the BankOperations class and overriding the finalize() method.

When the constructor throws an exception, the garbage collector waits to grab the object reference. However, the object cannot be garbage-collected until after the finalizer completes its execution. The attacker's finalizer obtains and stores a reference by using the this keyword. Consequently, the attacker can maliciously invoke any instance method on the base class by using the stolen instance reference. This attack can even bypass a check by a security manager.

public class Interceptor extends BankOperations {
  private static Interceptor stealInstance = null;

  public static Interceptor get() {
    try {
      new Interceptor();
    } catch (Exception ex) {/* ignore exception */}
    try {
      synchronized(Interceptor.class) {
        while (stealInstance == null) {
          System.gc();
          Interceptor.class.wait(10);
        }
      }
    } catch(InterruptedException ex) { return null; }
    return stealInstance;
  }

  public void finalize() {
    synchronized(Interceptor.class) {
      stealInstance = this;
      Interceptor.class.notify();
    }
    System.out.println("Stole the instance in finalize of " + this);
  }
}

The attacker's code intentionally violates rule MET12-J. Do not use finalizers to exploit the vulnerable code.

public class AttackerApp { // Invoke class and gain access to the restrictive features
  public static void main(String[] args) {
    Interceptor i = Interceptor.get(); // stolen instance

    // Can store the stolen object though this should have printed "Invalid Object!"
    Storage.store(i);

    // Now invoke any instance method of BankOperations class
    i.greet();

    UserApp.main(args); // Invoke the original UserApp
  }
}

Compliance with the rules ERR00-J. Do not suppress or ignore checked exceptions and ERR03-J. Restore prior object state on method failure can help to ensure that fields are appropriately initialized in catch blocks. A developer who explicitly initializes the variable to null is more likely to document this behavior so that other programmers or clients include the appropriate null checks where required. Moreover, this guarantees initialization safety in a multi-threaded scenario.

Compliant Solution (final)

This compliant solution declares the partially initialized class final so that it cannot be extended.

public final class BankOperations {
  // ...
}

Compliant Solution (final finalize())

If the class itself can not be declared final, it can still thwart the finalizer attack by declaring its own finalize() method, and making it final.

public final class BankOperations {
  public final void finalize() {
    // do nothing
  }
}

This falls under EX1 of MET12-J. Do not use finalizers.

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

This compliant solution applies to Java SE 6 and later versions, where a finalizer is prevented from being executed when an exception is thrown before the java.lang.Object constructor exits [[SCG 2009]].

In the public constructor, the method call performSSNVerification() is passed as an argument to a private constructor. Also, the performSSNVerification() method actually throws an exception rather than returning false if the security check fails.

public class BankOperations {
  public BankOperations() {
    this( performSSNVerification());
  }

  private BankOperations(boolean secure) {
    // secure is always true
    // constructor without any security checks
  }

  private static boolean performSSNVerification() {
    // Returns true if data entered is valid, else throws a SecurityException
    // Assume that the attacker just enters invalid SSN; so this method always throws the exception
    throw new SecurityException("Invalid SSN!");
  }

  // ...remainder of BankOperations class definition
}

The first statement in any constructor must be a call to either a super constructor or to another constructor in the same class. If a constructor call was not provided in the public constructor, the default constructor of the superclass executes. Unfortunately, this could allow a finalizer to be added and executed if the superclass constructor exited before the security check.

Compliant Solution (initialized flag)

Rather than throwing an exception, this compliant solution uses an initialized flag to indicate if an object was successfully constructed. The flag is initialized to false and set to true when the constructor completes successfully.

class BankOperations {
  private volatile boolean initialized = false;

  public BankOperations() {
    if (!performSSNVerification()) {
      throw new SecurityException("Invalid SSN!");
    }

    this.initialized = true; // object construction successful
  }

  private boolean performSSNVerification() {
    return false;
  }

  public void greet() {
    if (!this.initialized) {
      throw new SecurityException("Invalid SSN!");
    }

    System.out.println("Welcome user! You may now use all the features.");
  }
}

The initialized flag prevents any attempt to access the object's methods if the object is not fully constructed. Because each method must check the initialized flag to detect a partially constructed object, this solution imposes a speed penalty on the program. It is also harder to maintain because it is easy for a maintainer to add a method that fails to check the initialized flag.

According to Charlie Lai [[Lai 2008]]:

"If an object is only partially initialized, its internal fields likely contain safe default values such as null. Even in an untrusted environment, such an object is unlikely to be useful to an attacker. If the developer deems the partially initialized object state secure, then the developer doesn't have to pollute the class with the flag. The flag is necessary only when such a state isn't secure or when accessible methods in the class perform sensitive operations without referencing any internal field."

Noncompliant Code Example (Class Variable)

This noncompliant code example uses a non-final class variable. The Java Language Specification does not mandate complete initialization and safe publication even though a static initializer has been used. Note that, in the event of an exception during initialization, the variable can be incorrectly initialized.

class Trade {
  private static Stock s;
  static {
    try {
      s = new Stock();
    } catch (IOException e) {
      /* does not initialize s to a safe state */
    }
  }
  // ...
}

Compliant Solution (Final Class Variable)

This compliant solution guarantees safe publication by declaring the Stock field to be final.

private static final Stock s;  // final

Unlike the previous compliant solution, however, this approach permits a possibly-null value but guarantees that a non-null value refers to a completely initialized object.

Risk Assessment

Allowing access to a partially initialized object can provide an attacker with an opportunity to resurrect the object before or during its finalization; as a result, the attacker can bypass any security checks.

Automated Detection

Automated detection for this rule appears infeasible in the general case. Some instances of non-final classes whose constructors can throw exceptions could be straightforward to diagnose.

Related Vulnerabilities

Vulnerability CVE-2008-5339 concerns a series of vulnerabilities in Java. In one of the vulnerabilities, an applet causes an object to be deserialized using ObjectInputStream.readObject(), but the input is controlled by an attacker. The object actually read is a serializable subclass of ClassLoader, and it has a readObject() method that stashes the object instance into a static variable; consequently, the object survives the serialization. As a result, the applet manages to construct a ClassLoader object by passing the restrictions against this in an applet, and the ClassLoader allows it to construct classes that are not subject to the security restrictions of an applet. This vulnerability is described in depth in rule "SER09-J. Do not deserialize from a privileged context."

Related Guidelines

Bibliography

[!The CERT Oracle Secure Coding Standard for Java^button_arrow_left.png!]      [!The CERT Oracle Secure Coding Standard for Java^button_arrow_up.png!]      [!The CERT Oracle Secure Coding Standard for Java^button_arrow_right.png!]