Explicit Call to Finalize()
Draft Base
Structure: Simple
Description
The product makes an explicit call to the finalize() method from outside the finalizer.
While the Java Language Specification allows an object's finalize() method to be called from outside the finalizer, doing so is usually a bad idea. For example, calling finalize() explicitly means that finalize() will be called more than once: the first time will be the explicit call and the last time will be the call that is made after the object is garbage collected.
Common Consequences 1
Scope: IntegrityOther
Impact: Unexpected StateQuality Degradation
Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)Potential Mitigations 1
Phase: ImplementationTesting
Do not make explicit calls to finalize(). Use static analysis tools to spot such instances.
Demonstrative Examples 1
The following code fragment calls finalize() explicitly:
Code Example:
Bad
Java
// time to clean up* widget.finalize();
Applicable Platforms
Languages:
Java : Undetermined
Modes of Introduction
Implementation
Related Weaknesses
Taxonomy Mapping
- The CERT Oracle Secure Coding Standard for Java (2011)
- Software Fault Patterns