Exécuter une analyse statique (SAST) sur le code source à la recherche du motif non sécurisé dans le flux de données.
CWE-772 Base Brouillon
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…
Définition
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.
Impact réel
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).
Comment les attaquants l'exploitent
Parcours de l'attaquant étape par étape
- 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.
Exemple de code vulnérable
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);
}
} Exemple de code sécurisé
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.
Liste de contrôle de prévention
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).
Signaux de détection
How to detect CWE-772
Exécuter des tests de sécurité applicative dynamique (DAST) contre le point de terminaison en ligne.
Surveiller les journaux runtime pour détecter des traces d'exception inhabituelles, des entrées malformées ou des tentatives de contournement d'autorisation.
Revue de code : signaler tout nouveau code qui traite les entrées de cette surface sans utiliser les helpers du framework validés.
Plexicus détecte automatiquement CWE-772 et ouvre une PR de correction en moins de 60 secondes.
Codex Remedium analyse chaque commit, identifie cette faiblesse précise et livre une pull request prête à être relue avec le correctif. Pas de tickets. Pas de transferts.
Questions fréquentes Qu'est-ce que CWE-772 ?
Quelle est la gravité de CWE-772 ?
Quels langages ou plateformes sont affectés par CWE-772 ?
Comment puis-je prévenir CWE-772 ?
Comment Plexicus détecte et corrige CWE-772 ?
Où puis-je en savoir plus sur CWE-772 ?
Frequently asked questions
Qu'est-ce que 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.
Quelle est la gravité de CWE-772 ?
MITRE évalue la probabilité d'exploitation comme Élevée — cette faiblesse est activement exploitée et doit être priorisée pour la remédiation.
Quels langages ou plateformes sont affectés par CWE-772 ?
MITRE lists the following affected platforms: Mobile.
Comment puis-je prévenir CWE-772 ?
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…
Comment Plexicus détecte et corrige CWE-772 ?
Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-772 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.
Où puis-je en savoir plus sur CWE-772 ?
MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/772.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.
Faiblesses associées
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 Frère
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 Frère
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 Frère
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 Frère
Incomplete Cleanup
This vulnerability occurs when an application fails to properly remove temporary files, data structures, or system resources after they…
CWE-761 Frère
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 Frère
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 Frère
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 Frère
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…
Prêt quand vous l'êtes
Arrêtez de payer par développeur.
Commencez à fermer la boucle.
Plexicus est l'ASPM natif IA qui scanne, filtre, corrige, penteste et explique — de façon autonome. Développeurs illimités, dépôts illimités, actions IA à usage équitable. Vrai niveau gratuit, €269/mo annuel quand vous êtes prêt.