SV.EXPOSE.FIN
This error is detected when a class has a public finalize() method.
Vulnerability and risk
Because applets can persist after the Web browser leaves the page that contains them, it becomes important to protect applets from each other. Otherwise, an attacker's applet could deliberately sabotage a third party's applet. In many environments, it would be unacceptable for an applet to even learn of the existence of another applet. In Netscape Navigator 3.0, AppletContext.getApplets() is careful to return handles only to applets on the same Web page as the caller. However, an applet could easily get a handle to the top-level ThreadGroup and then enumerate every thread running in the system, including threads belonging to other arbitrary applets. The Java runtime encodes the applet's class name in its thread name, so a rogue applet can now learn the names of all applets running in the system. In addition, an applet could call the stop() or setPriority() methods on threads in other applets. The SecurityManager checked only that applets could not alter the state of system threads; there were no restraints on applets altering other applet threads. Netscape Navigator 4.0 prevents an attacker from seeing threads belonging to applets on other Web pages, in the same way it protects applets. Internet Explorer allows an applet to see those threads, but calls to stop() or setPriority() have no effect. An insidious form of this attack involves a malicious applet that lies dormant except when a particular victim applet is resident. When the victim applet is running, the malicious applet randomly mixes degradation of service attacks with attacks on the victim applet's threads. The result is that the user sees the victim applet as slow and buggy. Attacker applet can use security vulnerabilities to modify internal state of victim applet, so it is important to keep visibility of methods and field as low as possible, avoid static fields and use final as much as possible.
Klocwork security vulnerability (SV) checkers identify calls that create potentially dangerous data; these calls are considered unsafe sources. An unsafe source can be any data provided by the user, since the user could be an attacker or has the potential for introducing human error.
Mitigation and prevention
This vulnerability can be mitigated by making all finalize() methods protected.
Example 1
public void finalize() throws Throwable {
try {
close(); // close open files
} finally {
super.finalize();
}
}SV.EXPOSE.FIN is reported for line 10: Method finalize() should have protected access modifier, not public.