An attacker can maliciously obtain the instance of an object when a constructor for a non-final class throws an exception before it completes the initialization of the new object. For example, an attack that uses the finalizer construct allows an attacker to invoke arbitrary methods within the class despite authorization measures, even if the class methods are protected by a security manager.
h2. Noncompliant Code Example
This noncompliant code example, based on an example by Kabutz \[[Kabutz 2001|AA. Bibliography#Kabutz 01]\], defines the constructor of {{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}}.
The constructor throws a {{SecurityException}} when SSN verification fails. The {{UserApp}} class appropriately catches this exception and displays an access denied message. However, this fails to prevent a malicious program from invoking methods of the partially initialized class {{BankOperations}}, as illustrated in the additional code below.
{code:bgColor=#FFcccc}
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");
}
}
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;
}
}
}
{code}
Even whenIf a malicious subclass catches the {{SecurityException}} thrown by the {{BankOperations}} constructor, it remainsis still unable to cause further harm by obtainingbecause the new object instance has gone out of scope. RatherInstead, an attacker can exploit this code by extending the {{BankOperations}} class and overriding the {{finalize()}} method. The essencegoal of the attack is theto capture of a reference to athe partially initialized object of the base{{BankOperation}} class.
When the constructor throws an exception, the garbage collector waits to grab the object reference. However, the object cannot becomebe garbage-collected until _after_ the finalizer completes its execution. The attacker's overridden 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 securitycheck manager checkby a security manager.
{code}
public class Interceptor extends BankOperations {
private static Interceptor stealInstance = null;
public static Interceptor get() {
try {
new Interceptor();
} catch (Exception ex) { } //* Ignoreignore theexception 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("Stolen the instance in finalize of " + this);
}
}
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
}
}
{code}
The attacker's code violates the guideline [MET18-J. Avoid using finalizers].
h2. Compliant Solution ({{final}})
This compliant solution declares the partially-initialized class {{final}} so that it cannot be extended.
{code:bgColor=#ccccff}
public final class BankOperations {
// ...
}
{code}
{mc}
/**
This is an example of a finalizer attack in serialization. (Deserialization of cyclic references)
*/
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InvalidObjectException;
import java.io.ObjectInputStream;
import java.io.ObjectInputValidation;
import java.io.ObjectOutputStream;
import java.io.Serializable;
class A implements Serializable, ObjectInputValidation {
B b;
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
System.out.println("invoked");
in.registerValidation(this, 5);
in.defaultReadObject();
}
public void doSomething1(ObjectInputStream ois) throws IOException, ClassNotFoundException {
ois.readObject();
}
public void doSomething2() {
System.out.println("bypassed");
}
public void validateObject() throws InvalidObjectException {
throw new InvalidObjectException("Something is wrong");
}
}
class B implements Serializable { C c; }
class C implements Serializable { A a; }
class Test {
public static void main( String [] args ) throws IOException, ClassNotFoundException {
A a = new A();
a.b = new B();
a.b.c = new C();
a.b.c.a = a;
FileOutputStream fos = new FileOutputStream("c:\\cmu\\cyclic.txt");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(a);
Interceptor i = Interceptor.get();
i.doSomething2();
}
}
class Interceptor extends A {
private static Interceptor stealInstance = null;
public static Interceptor get() {
try {
FileInputStream fis = new FileInputStream("c:\\cyclic.txt");
ObjectInputStream ois = new ObjectInputStream(fis);
new Interceptor().doSomething1(ois);
} catch(Exception ex) { } // Ignore the 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("Stolen the instance in finalize of " + this);
}
}
{mc}
h2. Compliant Solution (Java SE 6+, {{public}} and {{private}} constructors)
This compliant solution preventsis aspecific hostileto callerJava fromSE using6 a partially initialized instance of the class. In the case of the noncompliant code example,and onwards, where a finalizer is prevented from being executed when an exception is thrown before the {{BankOperationsjava.lang.Object}} class's superclass's constructor is called implicitly from the {{BankOperations}}constructor exits \[[SCG 2009|AA. Bibliography#SCG 09]\].
In the public constructor, justthe beforemethod the check. This exposes the partially initialized object to the finalizer attack.
In this compliant solution, the check is carried out before the superclass's constructor executes. This forbids hostile code from obtaining a partially initialized instancecall {{performSSNVerification()}} is passed as an argument to a {{private}} constructor. Also, the {{performSSNVerification()}} method actually throws an exception rather than returning {{false}} should the security check fail.
{code:bgColor=#ccccff}
public class BankOperations {
public BankOperations() {
this( performSSNVerification());
}
private BankOperations(boolean performSSNVerificationsecure) {
// 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!");
}
public void greet() {
System.out.println("Welcome user! You may now use all the features.");
}
// ...remainder of BankOperations class definition
}
{code}
ThisThe compliantfirst solutionstatement isin specificany toconstructor Javamust SEbe 6a andcall onwards,to whereeither a finalizersuper isconstructor, preventedor fromto beinganother executed when an exception is thrown before the {{java.lang.Object}} constructor exits \[[SCG 2009|AA. Bibliography#SCG 09]\].
The method call {{performSSNVerification()}} is passed as an argument to a {{private}} constructor because the first statement in a constructor must be a call to either a super constructor, or to another constructor in the same subclass. When such a call is not provided, the default constructor of the superclass executes. This is not desirable because should the superclass constructor exit before the security check, the class would be exposed to the perils of a finalizer being added and executed.
h2. Compliant Solution
When the API can be extended (consider a non-final class, for example), it is permissible to use a flag to signal the successful completion of object construction. This is shown below.
{code:bgColor=#ccccff}
class BankOperations {
public volatile boolean initializedconstructor in the same class. If a constructor call was not provided in the public constructor, the default constructor of the superclass would execute. This would not be desirable because should the superclass constructor exit before the security check, the class would be exposed to the perils of a finalizer being added and executed.
h2. Compliant Solution (zombie flag)
This compliant solution uses a 'zombie' flag to indicate if an object was successfully constructed. The flag is set to {{true}}, and is set to {{false}} when the constructor completes successfully.
{code:bgColor=#ccccff}
class BankOperations {
private volatile boolean zombie = true;
public BankOperations() {
if (!performSSNVerification()) {
throw new SecurityException("Invalid SSN!");
}
zombie = false; // volatile flag
object construction succeeded
public}
BankOperations() {
private ifboolean (!performSSNVerification()) {
throw new SecurityException("Invalid SSN!"); return false;
}
public void elsegreet() {
if (zombie) {
initialized = true; // objectthrow construction succeeded new SecurityException("Invalid SSN!");
}
}
private boolean performSSNVerification() {
return falseSystem.out.println("Welcome user! You may now use all the features.");
}
}
{code}
The {{zombie}} flag
public void greet() {
if(initialized == true) {
System.out.println("Welcome user! You may now use all the features.");
// ...
}
else {
System.out.println("You are not permitted!");
}
}
}
{code}thwarts any attempt to access the object's methods if the object is not fully constructed. Since each method must check the {{zombie}} flag to detect a partially-constructed object, this solution imposes a speed penalty on the program. It is also harder to maintain, as it is easy for a maintainer to add a method that fails to check the {{zombie}} flag.
"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" \[[Lai 2008|AA. Bibliography#Lai 08]\].
h2. Exceptions
{anchor:OBJ04-EX1}
*OBJ04-EX1:* It is permissible to use the telescoping pattern when the overhead of the builder pattern is significant as compared to the number of parameters required to be initialized. This pattern prescribes a constructor to initialize the required parameters and individual constructors for each optional parameter that is added.
h2. 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; consequently, the attacker can bypass any security checks.
|| Guideline || Severity || Likelihood || Remediation Cost || Priority || Level ||
| OBJ04-J | high | probable | medium | {color:red}{*}P12{*}{color} | {color:red}{*}L1{*}{color} |
h3. Automated Detection
Automated detection for this guideline appears infeasible in the general case. Some instances of non-final classes whose constructors can throw exceptions may be straightforward to diagnose.
h3. 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 has managed to construct a {{ClassLoader}} object, by-passing the restrictions against doing so in an applet, and that {{ClassLoader}} allows it to construct classes that are not subject to the security restrictions of an applet. The vulnerability is described in depth in guideline [SER09-J. Do not deserialize from a privileged context].
Search for vulnerabilities resulting from the violation of this guideline on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+OBJ32-J].
h2. Bibliography
\[[API 2006|AA. Bibliography#API 06]\] [finalize()|http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#finalize()]
\[[Darwin 2004|AA. Bibliography#Darwin 04]\] Section 9.5, The Finalize Method
\[[Flanagan 2005|AA. Bibliography#Flanagan 05]\] Section 3.3, Destroying and Finalizing Objects
\[[JLS 2005|AA. Bibliography#JLS 05]\] [Section 12.6|http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.6], Finalization of Class Instances
\[[Kabutz 2001|AA. Bibliography#Kabutz 01]\] Issue 032 - Exceptional Constructors - Resurrecting the dead
\[[Lai 2008|AA. Bibliography#Lai 08]\]
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 4-2 Defend against partially initialized instances of non-final classes
\[[SCG 2009|AA. Bibliography#SCG 09]\] Guideline 1-2 Limit the extensibility of classes and methods
----
[!The CERT Oracle Secure Coding Standard for Java^button_arrow_left.png!|OBJ03-J. Do not use public static non-final variables] [!The CERT Oracle Secure Coding Standard for Java^button_arrow_up.png!|04. Object Orientation (OBJ)] [!The CERT Oracle Secure Coding Standard for Java^button_arrow_right.png!|OBJ05-J. Limit the extensibility of non-final classes and methods to trusted subclasses only]
| 