The program violates secure coding principles for mobile code by declaring a finalize() method public.
Extended Description
A program should never call finalize explicitly, except to call super.finalize() inside an implementation of finalize(). In mobile code situations, the otherwise error prone practice of manual garbage collection can become a security threat if an attacker can maliciously invoke one of your finalize() methods because it is declared with public access.
Time of Introduction
Implementation
Applicable Platforms
Languages
Java
Common Consequences
Scope
Effect
Confidentiality
Integrity
Availability
Technical Impact: Alter execution
logic; Execute unauthorized code or
commands; Modify application
data
Demonstrative Examples
Example 1
The following Java Applet code mistakenly declares a public
finalize() method.
(Bad Code)
Example
Language: Java
public final class urlTool extends Applet {
public void finalize() {
...
}
...
}
Mobile code, in this case a Java Applet, is code that is transmitted
across a network and executed on a remote machine. Because mobile code
developers have little if any control of the environment in which their
code will execute, special security concerns become relevant. One of the
biggest environmental threats results from the risk that the mobile code
will run side-by-side with other, potentially malicious, mobile code.
Because all of the popular web browsers execute code from multiple
sources together in the same JVM, many of the security guidelines for
mobile code are focused on preventing manipulation of your objects'
state and behavior by adversaries who have access to the same virtual
machine where your program is running.
Potential Mitigations
If you are using finalize() as it was designed, there is no reason to
declare finalize() with anything other than protected access.
Description
