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 searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
CWE-479 Variante Rascunho
Signal Handler Use of a Non-reentrant Function
This vulnerability occurs when a signal handler in your code calls a function that is not safe to re-enter. If that function is interrupted and called again before it finishes, it can corrupt memory…
Definição
What is CWE-479?
This vulnerability occurs when a signal handler in your code calls a function that is not safe to re-enter. If that function is interrupted and called again before it finishes, it can corrupt memory and crash your program or create security weaknesses.
Non-reentrant functions rely on global data or static memory to do their work. When a signal interrupts such a function and the handler calls the same function again, both invocations compete for and corrupt that shared state. Common examples include `malloc()`, `free()`, and `syslog()`, which use internal scratch space or metadata to track operations. This corruption can leave your application in an unpredictable and potentially exploitable state.
As a developer, you must ensure that only async-signal-safe functions are called from within a signal handler. The POSIX standard defines a specific list of these safe functions. Calling anything outside this list, especially standard library functions that manage memory or perform I/O, introduces this risk of re-entrancy corruption which can lead to denial of service or, in worst cases, allow an attacker to execute arbitrary code.
Impacto no mundo real
Real-world CVEs caused by CWE-479
-
signal handler calls function that ultimately uses malloc()
-
SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.
Como os atacantes a exploram
Trajeto do atacante passo a passo
- 1
Identificar um caminho de código que trata input não confiável sem validação.
- 2
Criar um payload que explora o comportamento inseguro — injeção, traversal, overflow ou abuso de lógica.
- 3
Entregar o payload através de um pedido normal e observar a reação da aplicação.
- 4
Iterar até que a resposta exponha dados, execute código do atacante ou escale privilégios.
Exemplo de código vulnerável
Vulnerable C
In this example, a signal handler uses syslog() to log a message:
char *message;
void sh(int dummy) {
syslog(LOG_NOTICE,"%s\n",message);
sleep(10);
exit(0);
}
int main(int argc,char* argv[]) {
...
signal(SIGHUP,sh);
signal(SIGTERM,sh);
sleep(10);
exit(0);
}
If the execution of the first call to the signal handler is suspended after invoking syslog(), and the signal handler is called a second time, the memory allocated by syslog() enters an undefined, and possibly, exploitable state. Exemplo de código seguro
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} 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-479
- Requirements Require languages or libraries that provide reentrant functionality, or otherwise make it easier to avoid this weakness.
- Architecture and Design Design signal handlers to only set flags rather than perform complex functionality.
- Implementation Ensure that non-reentrant functions are not found in signal handlers.
- Implementation Use sanity checks to reduce the timing window for exploitation of race conditions. This is only a partial solution, since many attacks might fail, but other attacks still might work within the narrower window, even accidentally.
Sinais de deteção
How to detect CWE-479
CWE-479
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Perguntas frequentes O que é o CWE-479?
Qual a gravidade do CWE-479?
Que linguagens ou plataformas são afetadas pelo CWE-479?
Como posso prevenir o CWE-479?
Como é que o Plexicus deteta e corrige o CWE-479?
Onde posso saber mais sobre o CWE-479?
Frequently asked questions
O que é o CWE-479?
This vulnerability occurs when a signal handler in your code calls a function that is not safe to re-enter. If that function is interrupted and called again before it finishes, it can corrupt memory and crash your program or create security weaknesses.
Qual a gravidade do CWE-479?
A MITRE classifica a probabilidade de exploração como Baixa — a exploração é pouco comum, mas a fraqueza deve mesmo assim ser corrigida quando descoberta.
Que linguagens ou plataformas são afetadas pelo CWE-479?
MITRE lists the following affected platforms: C, C++.
Como posso prevenir o CWE-479?
Require languages or libraries that provide reentrant functionality, or otherwise make it easier to avoid this weakness. Design signal handlers to only set flags rather than perform complex functionality.
Como é que o Plexicus deteta e corrige o CWE-479?
O motor SAST do Plexicus correlaciona a assinatura de fluxo de dados do CWE-479 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-479?
A MITRE publica a definição canónica em https://cwe.mitre.org/data/definitions/479.html. Pode também consultar a documentação da OWASP e do NIST para orientações adjacentes.
Fraquezas relacionadas
Weaknesses related to CWE-479
CWE-828 Pai
Signal Handler with Functionality that is not Asynchronous-Safe
This weakness occurs when a program's signal handler contains code that is not asynchronous-safe. This means the handler can be…
CWE-123 Pode preceder
Write-what-where Condition
A write-what-where condition occurs when an attacker can control both the data written and the exact memory location where it's written,…
Pronto para validar o que importa?
Pronto para validar o que importa.
O Plexicus é Proof-Driven AppSec: achados validados, compreensão contextual e remediação revisada — ancorada em evidência, escopada com você.