Führe statische Analyse (SAST) auf der Codebasis aus und suche im Datenfluss nach dem unsicheren Muster.
CWE-772 Base Draft
Missing Release of Resource after Effective Lifetime
This vulnerability occurs when a program fails to properly release a system resource—like memory, file handles, or network sockets—after it is no longer needed. This leads to a gradual accumulation…
Definition
What is CWE-772?
This vulnerability occurs when a program fails to properly release a system resource—like memory, file handles, or network sockets—after it is no longer needed. This leads to a gradual accumulation of unused resources, known as a resource leak.
Resource leaks happen when developers allocate resources but forget to include the cleanup logic, or when errors and exceptions prevent cleanup code from running. Common culprits include not closing database connections, leaving files open after reading, or not freeing memory in languages without automatic garbage collection. Over time, these leaks degrade performance and can cause the application to crash when it exhausts a critical resource like available file handles or memory.
To prevent this, developers should adopt patterns that guarantee cleanup, such as using try-finally blocks or modern language constructs like 'using' statements (C#) or 'try-with-resources' (Java). It's also crucial to audit code for all resource allocation points, ensure every 'open' or 'allocate' has a corresponding 'close' or 'free' in all execution paths, and leverage static analysis tools to detect potential leaks during development.
Auswirkungen in der Praxis
Real-world CVEs caused by CWE-772
-
Chain: anti-virus product encounters a malformed file but returns from a function without closing a file descriptor (CWE-775) leading to file descriptor consumption (CWE-400) and failed scans.
-
Sockets not properly closed when attacker repeatedly connects and disconnects from server.
-
Does not shut down named pipe connections if malformed data is sent.
-
Chain: memory leak (CWE-404) leads to resource exhaustion.
-
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
-
Port scan triggers CPU consumption with processes that attempt to read data from closed sockets.
-
Product allows resource exhaustion via a large number of calls that do not complete a 3-way handshake.
-
Chain: Return values of file/socket operations are not checked (CWE-252), allowing resultant consumption of file descriptors (CWE-772).
Wie Angreifer es ausnutzen
Angreiferpfad Schritt für Schritt
- 1
The following method never closes the new file handle. Given enough time, the Finalize() method for BufferReader should eventually call Close(), but there is no guarantee as to how long this action will take. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, the Operating System could use up all of the available file handles before the Close() function is called.
- 2
The good code example simply adds an explicit call to the Close() function when the system is done using the file. Within a simple example such as this the problem is easy to see and fix. In a real system, the problem may be considerably more obscure.
- 3
The following code attempts to open a new connection to a database, process the results returned by the database, and close the allocated SqlConnection object.
- 4
The problem with the above code is that if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.
- 5
This code attempts to open a connection to a database and catches any exceptions that may occur.
Verwundbares Codebeispiel
Vulnerable Java
The following method never closes the new file handle. Given enough time, the Finalize() method for BufferReader should eventually call Close(), but there is no guarantee as to how long this action will take. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, the Operating System could use up all of the available file handles before the Close() function is called.
private void processFile(string fName)
{
BufferReader fil = new BufferReader(new FileReader(fName));
String line;
while ((line = fil.ReadLine()) != null)
{
processLine(line);
}
} Sicheres Codebeispiel
Secure Java
The good code example simply adds an explicit call to the Close() function when the system is done using the file. Within a simple example such as this the problem is easy to see and fix. In a real system, the problem may be considerably more obscure.
private void processFile(string fName)
{
BufferReader fil = new BufferReader(new FileReader(fName));
String line;
while ((line = fil.ReadLine()) != null)
{
processLine(line);
}
fil.Close();
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Präventions-Checkliste
How to prevent CWE-772
- Requirements Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
- Implementation It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
- Operation / Architecture and Design Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
Erkennungssignale
How to detect CWE-772
Führe dynamische Application-Security-Tests gegen den Live-Endpoint aus.
Beobachte Runtime-Logs auf ungewöhnliche Exception-Traces, fehlerhafte Eingaben oder Versuche, Autorisierung zu umgehen.
Code Review: Markiere jeden neuen Code, der Eingaben von dieser Oberfläche ohne validierte Framework-Helper verarbeitet.
Plexicus erkennt CWE-772 automatisch und öffnet in unter 60 Sekunden einen Fix-PR.
Codex Remedium scannt jeden Commit, identifiziert genau diese Schwachstelle und liefert einen reviewer-ready Pull Request mit dem Patch. Keine Tickets. Keine Hand-offs.
Häufig gestellte Fragen Was ist CWE-772?
Wie gravierend ist CWE-772?
Welche Sprachen oder Plattformen sind von CWE-772 betroffen?
Wie kann ich CWE-772 verhindern?
Wie erkennt und behebt Plexicus CWE-772?
Wo erfahre ich mehr über CWE-772?
Frequently asked questions
Was ist CWE-772?
This vulnerability occurs when a program fails to properly release a system resource—like memory, file handles, or network sockets—after it is no longer needed. This leads to a gradual accumulation of unused resources, known as a resource leak.
Wie gravierend ist CWE-772?
MITRE stuft die Exploit-Wahrscheinlichkeit als hoch ein — diese Schwachstelle wird aktiv in freier Wildbahn ausgenutzt und sollte priorisiert behoben werden.
Welche Sprachen oder Plattformen sind von CWE-772 betroffen?
MITRE lists the following affected platforms: Mobile.
Wie kann ich CWE-772 verhindern?
Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated. It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the…
Wie erkennt und behebt Plexicus CWE-772?
Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-772 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.
Wo erfahre ich mehr über CWE-772?
MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/772.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.
Verwandte Schwachstellen
Weaknesses related to CWE-772
CWE-404 Parent
Improper Resource Shutdown or Release
This vulnerability occurs when a program fails to properly close or release a system resource—like a file handle, database connection, or…
CWE-1266 Sibling
Improper Scrubbing of Sensitive Data from Decommissioned Device
This vulnerability occurs when a system lacks a reliable method for administrators to permanently erase sensitive information before…
CWE-299 Sibling
Improper Check for Certificate Revocation
This vulnerability occurs when an application fails to properly verify whether a security certificate has been revoked, potentially…
CWE-401 Sibling
Missing Release of Memory after Effective Lifetime
This vulnerability occurs when a program allocates memory but fails to properly release it after it's no longer needed, causing a gradual…
CWE-459 Sibling
Incomplete Cleanup
This vulnerability occurs when an application fails to properly remove temporary files, data structures, or system resources after they…
CWE-761 Sibling
Free of Pointer not at Start of Buffer
This vulnerability occurs when a program incorrectly frees a memory pointer that no longer points to the beginning of the allocated heap…
CWE-762 Sibling
Mismatched Memory Management Routines
This vulnerability occurs when a program uses incompatible functions to allocate and free memory. For example, freeing memory with a…
CWE-763 Sibling
Release of Invalid Pointer or Reference
This vulnerability occurs when a program tries to free a memory resource back to the system but uses an incorrect deallocation method or…
CWE-775 Sibling
Missing Release of File Descriptor or Handle after Effective Lifetime
This vulnerability occurs when a program fails to properly close file descriptors or handles after they are no longer needed, leaving…
Bereit, wenn du es bist
Schluss mit dem Bezahlen pro Entwickler.
Schließ den Kreislauf.
Plexicus ist die KI-native ASPM, die scannt, filtert, fixt, pentestet und erklärt — autonom. Unbegrenzte Entwickler, unbegrenzte Repos, Fair-Use-KI-Aktionen. Echter kostenloser Tarif, €269/mo jährlich, wenn du bereit bist.