CWE-772 Base Rascunho High likelihood

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…

Definição

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.
Vulnerability Diagram CWE-772
Missing Release of Resource acquire() conn = pool.get() work() throws no try/finally return early no release pool empty over time Each error path leaks a resource; the pool slowly runs dry.
Impacto no mundo real

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).

Como os atacantes a exploram

Trajeto do atacante passo a passo

  1. 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. 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. 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. 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. 5

    This code attempts to open a connection to a database and catches any exceptions that may occur.

Exemplo de código vulnerável

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.

Vulnerável Java
private void processFile(string fName)
  {
  	BufferReader fil = new BufferReader(new FileReader(fName));
  	String line;
  	while ((line = fil.ReadLine()) != null)
  	{
  		processLine(line);
  	}
  }
Exemplo de código seguro

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.

Seguro Java
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.
Lista de verificação de prevenção

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).
Sinais de deteção

How to detect CWE-772

SAST High

Executar análise estática (SAST) na base de código à procura do padrão inseguro no fluxo de dados.

DAST Moderate

Executar testes dinâmicos de segurança de aplicações (DAST) contra o endpoint em execução.

Runtime Moderate

Monitorizar os registos em tempo de execução para traços de exceção invulgares, input malformado ou tentativas de contornar a autorização.

Code review Moderate

Revisão de código: sinalizar qualquer novo código que trate input desta superfície sem usar os ajudantes validados do framework.

Correção automática do Plexicus

O Plexicus deteta automaticamente o CWE-772 e abre um PR de correção em menos de 60 segundos.

O Codex Remedium analisa cada commit, identifica esta fraqueza exata e entrega um pull request pronto para revisão com o patch. Sem tickets. Sem transferências.

Perguntas frequentes

Frequently asked questions

O que é o 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.

Qual a gravidade do CWE-772?

A MITRE classifica a probabilidade de exploração como Alta — esta fraqueza é ativamente explorada em campo e deve ser priorizada para remediação.

Que linguagens ou plataformas são afetadas pelo CWE-772?

MITRE lists the following affected platforms: Mobile.

Como posso prevenir o 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…

Como é que o Plexicus deteta e corrige o CWE-772?

O motor SAST do Plexicus correlaciona a assinatura de fluxo de dados do CWE-772 em cada commit. Quando é encontrada uma correspondência, o nosso agente Codex Remedium abre um PR de correção com o código corrigido, testes e um resumo de uma linha para o revisor.

Onde posso saber mais sobre o CWE-772?

A MITRE publica a definição canónica em https://cwe.mitre.org/data/definitions/772.html. Pode também consultar a documentação da OWASP e do NIST para orientações adjacentes.

Fraquezas relacionadas

Weaknesses related to CWE-772

CWE-404 Pai

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 Irmão

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 Irmão

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 Irmão

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 Irmão

Incomplete Cleanup

This vulnerability occurs when an application fails to properly remove temporary files, data structures, or system resources after they…

CWE-761 Irmão

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 Irmão

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 Irmão

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 Irmão

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…

Pronto quando você estiver

Pare de pagar por desenvolvedor.
Comece a fechar o ciclo.

O Plexicus é o ASPM nativo de IA que verifica, filtra, corrige, pentesta e explica — de forma autónoma. Programadores ilimitados, repos ilimitados, ações de IA de utilização justa. Nível gratuito real, €269/mo anual quando estiver pronto.