...
The following table summarizes these three approaches:
Solution | Uninitialized Values | Partially Initialized Objects |
Exception in constructor | Prevents | Does not prevent |
Final field | Prevents | Prevents |
Initialized flag | Detects | Detects |
Noncompliant Code Example (Finalizer Attack)
...
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 (Static Variable)
...
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.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
OBJ11-J | High | Probable | Medium | P12 | L1 |
Automated Detection
Automated detection for this rule is infeasible in the general case. Some instances of nonfinal classes whose constructors can throw exceptions could be straightforward to diagnose.
| Tool | Version | Checker | Description |
|---|---|---|---|
| Parasoft Jtest |
| CERT.OBJ11.EPNFC | Do not throw exceptions from constructors of "public" non-"final" classes |
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
Guideline 4-5 / EXTEND-5: Limit the extensibility of classes and methods |
Bibliography
[API 2006] | |
Section 9.5, "The Finalize Method" | |
Section 3.3, "Destroying and Finalizing Objects" | |
[JLS 2015] | §8.3.1, Field Modifiers final Field Semantics" |
Issue 032, "Exceptional Constructors—Resurrecting the Dead" | |
[Lai 2008] | "Java Insecurity: Accounting for Subtleties That Can Compromise Code" |
| [Masson 2011] | "Secure Your Code against the Finalizer Vulnerability" |
...
...