1. Home
  2. CWE Database
  3. CWE-583
Variant · Low-Medium

CWE-583: finalize() Method Declared Public

The product violates secure coding principles for mobile code by declaring a finalize() method public.

CWE-583 · Variant Level ·1 Mitigations

Description

The product violates secure coding principles for mobile code by declaring a finalize() method public.

A product 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 a finalize() method because it is declared with public access.

Potential Impact

Confidentiality, Integrity, Availability

Alter Execution Logic, Execute Unauthorized Code or Commands, Modify Application Data

Demonstrative Examples

The following Java Applet code mistakenly declares a public finalize() method.
Bad
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 product is running.

Mitigations & Prevention

Implementation

If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access.

Detection Methods

  • Automated Static Analysis High — 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 sea

CWE-668: Exposure of Resource to Wrong Sphere

The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the...

Taxonomy Mappings

  • The CERT Oracle Secure Coding Standard for Java (2011): MET12-J — Do not use finalizers
  • Software Fault Patterns: SFP28 — Unexpected access points

Frequently Asked Questions

What is CWE-583?

CWE-583 (finalize() Method Declared Public) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. The product violates secure coding principles for mobile code by declaring a finalize() method public.

How can CWE-583 be exploited?

Attackers can exploit CWE-583 (finalize() Method Declared Public) to alter execution logic, execute unauthorized code or commands, modify application data. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-583?

Key mitigations include: If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access.

What is the severity of CWE-583?

CWE-583 is classified as a Variant-level weakness (Low-Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.