CWE-672 Classe Rascunho

Operation on a Resource after Expiration or Release

This vulnerability occurs when a program continues to use a resource—like memory, a file handle, or a network connection—after it has been freed, closed, or is no longer valid.

Definição

What is CWE-672?

This vulnerability occurs when a program continues to use a resource—like memory, a file handle, or a network connection—after it has been freed, closed, or is no longer valid.
Think of this as using a hotel key card after you've checked out. The system has marked that resource as available for reuse, but your code still holds a reference to it. When you try to read, write, or execute operations using this 'stale' reference, the results are unpredictable. The program might crash, leak sensitive data from the now-reallocated memory, or allow an attacker to hijack the resource for their own purposes. To prevent this, developers must carefully manage the lifecycle of all resources. This means ensuring that every 'malloc' has a matching 'free', every 'open' has a 'close', and that pointers or handles are set to NULL or another invalid state immediately after release. Using modern language features like smart pointers in C++ or try-with-resources in Java can automate this cleanup and make these dangerous 'use-after-free' and 'use-after-close' errors much less likely.
Impacto no mundo real

Real-world CVEs caused by CWE-672

  • CVE-2009-3547

    Chain: race condition (CWE-362) might allow resource to be released before operating on it, leading to NULL dereference (CWE-476)

Como os atacantes a exploram

Trajeto do atacante passo a passo

  1. 1

    The following code shows a simple example of a use after free error:

  2. 2

    When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.

  3. 3

    The following code shows a simple example of a double free error:

  4. 4

    Double free vulnerabilities have two common (and sometimes overlapping) causes:

  5. 5

    - Error conditions and other exceptional circumstances - Confusion over which part of the program is responsible for freeing the memory

Exemplo de código vulnerável

Vulnerable C

The following code shows a simple example of a use after free error:

Vulnerável C 
char* ptr = (char*)malloc (SIZE);
  if (err) {
  	abrt = 1;
  	free(ptr);
  }
  ...
  if (abrt) {
  	logError("operation aborted before commit", ptr);
  }
Exemplo de código seguro

Secure C

However, the call to the method logError includes the messageBody after the memory for messageBody has been released using the free method. This can cause unexpected results and may lead to system crashes. A variable should never be used after its memory resources have been released.

Seguro C 
...
  messageBody = (char*)malloc(length*sizeof(char));
  messageBody = &message[1][0];
  int success = processMessageBody(messageBody);
  if (success == ERROR) {
  	result = ERROR;
  	logError("Error processing message", messageBody);
  	free(messageBody);
  }
  ...
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-672

  • Architecture Use safe-by-default frameworks and APIs that prevent the unsafe pattern from being expressible.
  • Implementation Validate input at trust boundaries; use allowlists, not denylists.
  • Implementation Apply the principle of least privilege to credentials, file paths, and runtime permissions.
  • Testing Cover this weakness in CI: SAST rules + targeted unit tests for the data flow.
  • Operation Monitor logs for the runtime signals listed in the next section.
Sinais de deteção

How to detect CWE-672

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

Obter uma demonstração Experimente o Plexicus gratuitamente
Perguntas frequentes

Frequently asked questions

O que é o CWE-672?

This vulnerability occurs when a program continues to use a resource—like memory, a file handle, or a network connection—after it has been freed, closed, or is no longer valid.

Qual a gravidade do CWE-672?

A MITRE não publicou uma classificação de probabilidade de exploração para esta fraqueza. Trate-a como impacto médio até o seu modelo de ameaças provar o contrário.

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

MITRE lists the following affected platforms: Mobile.

Como posso prevenir o CWE-672?

Use safe-by-default frameworks, validate untrusted input at trust boundaries, and apply the principle of least privilege. Cover the data-flow signature in CI with SAST.

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

O motor SAST do Plexicus correlaciona a assinatura de fluxo de dados do CWE-672 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-672?

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

Fraquezas relacionadas

Weaknesses related to CWE-672

CWE-666 Pai

Operation on Resource in Wrong Phase of Lifetime

This vulnerability occurs when software interacts with a resource—like memory, a file, or a network connection—at an incorrect stage of…

CWE-415 Irmão

Double Free

A double free vulnerability occurs when a program mistakenly calls the 'free()' function twice on the same block of memory.

CWE-593 Irmão

Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created

This vulnerability occurs when an application modifies an OpenSSL context object after it has already been used to create active SSL/TLS…

CWE-605 Irmão

Multiple Binds to the Same Port

This vulnerability occurs when a system's socket configuration allows multiple applications to bind to the same network port…

CWE-826 Irmão

Premature Release of Resource During Expected Lifetime

This happens when software incorrectly frees or closes a resource—like memory, a file handle, or a network connection—while that resource…

CWE-298 Filho

Improper Validation of Certificate Expiration

This vulnerability occurs when an application fails to properly check if a digital certificate has expired, potentially trusting…

CWE-324 Filho

Use of a Key Past its Expiration Date

This vulnerability occurs when an application continues to use a cryptographic key or password after its designated expiration date. Doing…

CWE-416 Filho

Use After Free

Use After Free happens when a program continues to use a pointer to a memory location after that memory has been freed. This can lead to…

CWE-613 Filho

Insufficient Session Expiration

Insufficient session expiration occurs when an application allows old session tokens or IDs to remain valid for too long, letting…

Recursos

Further reading

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.

Começar grátis Reservar uma demo