For a non-final class, if a constructor throws an exception before fully initializing the class, it becomes possible to maliciously obtain its instance. For example, an attack that uses the finalizer
construct allows an attacker to invoke arbitrary methods within the class despite of all authorization measures.
...
Noncompliant Code Example
The constructor of BankOperations
class performs the SSN validation using performSSNVerification()
. Assume that an attacker does not know the correct SSN, thus as a result this method trivially returns false
in this example. A SecurityException
is forcefully thrown as a result. The UserApp
class appropriately catches this and an access denied message is displayed. However, it is still possible for a malicious program to invoke methods of the partially initialized class BankOperations
. This is illustrated in the code that follows this example.
...
Code Block |
---|
public class Interceptor extends BankOperations { private static Interceptor stealInstance = null; public static Interceptor get() { try { new Interceptor(); } 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); } } public class AttackerApp { //invoke this class and gain access to the restrictive features public static void main(String[] args) { Interceptor i = Interceptor.get(); i.greet(); //now invoke any method of BankOperations class UserApp.main(args); //Invoke the original UserApp } } |
Compliant Solution
One compliant solution is to use an initialization flag that is explicitly set after the constructor has finished initializing the class. This flag should be tested before code is executed in any method. This (rather) imposing solution is recommended for security sensitive applications. For others, it is reasonable to initialize the default values of class variables to something like null
. \Check this
Code Block | ||
---|---|---|
| ||
public class BankOperations { public BankOperations() { if (!performSSNVerification()) { throw new SecurityException("Invalid SSN!"); } else initialized = true; } private boolean performSSNVerification() { return false; } public static void greet() { if(initialized == true) { System.out.println("Welcome user! You may now use all the features."); //other authorized code } else System.out.println("You are not permitted!"); } } |
Risk Assessment
TODO
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
OBJ32-J | ?? | ?? | ?? | P?? | L?? |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
Sun Secure Coding http://java.sun.com/security/seccodeguide.html
The Java Specialists' Newsletter Issue 032 - Exceptional Constructors - Resurrecting the dead Author: Dr. Heinz M. Kabutz
JLS, 12.6 Finalization of Class Instances
Effective Java: Programming Language Guide, Item 6, Avoid finalizers
Java Cookbook, Ian Darwin, 9.5 The Finalize Method
Java in a nutshell, 3.3. Destroying and Finalizing Objects
Java API Documentation http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#finalize()