Page History

...

There are three common approaches to dealing with the problem of partially initialized objects:

• Exception in constructor. This approach throws an exception in the object's constructor. Unfortunately, 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.

• Final field. Declaring the variable that is initialized to the object as final prevents the object from being partially initialized. The compiler produces a warning when there is a possibility that the variable's object might not be fully initialized. Declaring the variable final also guarantees initialization safety in multithreaded code. According to The Java Language Specification (JLS), §17.5, "Final final Field Semantics" [JLS 20052015], "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 preinitialized values of the object.

• Initialized flag. This approach allows uninitialized or partially initialized objects 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 the object has been correctly initialized.

The following table summarizes these three approaches:

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 social security number (SSN) verification using the method performSSNVerification(). The implementation of the performSSNVerification() method assumes that an attacker does not know the correct SSN and trivially returns false.

public class BankOperations {
  public BankOperations() {
    if (!performSSNVerification()) {
      throw new SecurityException("Access Denied!");
    }
  }

  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 Storage {
  private static BankOperations bop;

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

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 goal of the attack is to capture a reference to the partially initialized object of the BankOperations 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. This attack intentionally violates rule MET12-J. Do not use finalizers.

...

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

...

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

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

This solution is allowed under exception MET12-J-EX1, which permits a class to use an empty final finalizer to prevent a finalizer attack.

...

Consequently, to execute potentially exception-raising checks before the java.lang.Object constructor exits, the programmer must place them in an argument expression of an explicit constructor invocation. For example, the single constructor can be split into three parts: a public constructor , whose interface remains unchanged; , a private constructor that takes (at least) one argument and performs the actual work of the original constructor; , and a method that performs the checks. The public constructor invokes the private constructor on its first line while invoking the method as an argument expression. All code in the expression will be executed before the private constructor, thereby ensuring that any exceptions will be raised before the java.lang.Object constructor is invoked.

This compliant solution demonstrates the design. Note that the performSSNVerification() method is modified to throw 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
    // constructorConstructor 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
}

...

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

class BankOperations {
  private volatile boolean initialized = false;

  public BankOperations() {
    if (!performSSNVerification()) {
      return;                throw// new SecurityException("Invalid SSN!");object construction failed
    }

    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.");
  }
}

...

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.

The initialized flag is volatile to ensure that the setting of the flag to true happens-before any reads of the variable. The current code does not allow for multiple threads to read the field before the constructor terminates, but this object could always be subclassed and run in an environment where multiple threads can access the variable.

Noncompliant Code Example (Noncompliant Code Example (Static Variable)

This noncompliant code example uses a nonfinal static variable. The Java Language SpecificationJLS 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.

...

This compliant solution guarantees safe publication by declaring the Stock field final:

private static final Stock s;

...

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 security checks.

Automated Detection

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

Related Vulnerabilities

CVE-2008-53395353 describes a collection 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 SER08-J. Minimize privileges before deserializing from a privileged context.

Related Guidelines

Bibliography

...

...

Image Modified Image Modified Image Modified