CWE-479 Variant Draft Low likelihood

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…

Definition

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.
Auswirkungen in der Praxis

Real-world CVEs caused by CWE-479

  • CVE-2005-0893

    signal handler calls function that ultimately uses malloc()

  • CVE-2004-2259

    SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.

Wie Angreifer es ausnutzen

Angreiferpfad Schritt für Schritt

  1. 1

    Identifiziere einen Codepfad, der nicht vertrauenswürdige Eingaben ohne Validierung verarbeitet.

  2. 2

    Erzeuge eine Payload, die das unsichere Verhalten auslöst — Injection, Traversal, Overflow oder Logik-Missbrauch.

  3. 3

    Liefere die Payload über einen normalen Request aus und beobachte die Reaktion der Anwendung.

  4. 4

    Iteriere, bis die Antwort Daten preisgibt, Angreifer-Code ausführt oder Berechtigungen eskaliert.

Verwundbares Codebeispiel

Vulnerable C

In this example, a signal handler uses syslog() to log a message:

Verwundbar C 
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.
Sicheres Codebeispiel

Secure pseudo

Sicher 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.
Präventions-Checkliste

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

How to detect CWE-479

Automated Static Analysis High

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

Plexicus Auto-Fix

Plexicus erkennt CWE-479 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.

Demo anfordern Plexicus kostenlos testen
Häufig gestellte Fragen

Frequently asked questions

Was ist 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.

Wie gravierend ist CWE-479?

MITRE stuft die Exploit-Wahrscheinlichkeit als niedrig ein — eine Ausnutzung ist selten, die Schwachstelle sollte aber dennoch behoben werden, sobald sie entdeckt wird.

Welche Sprachen oder Plattformen sind von CWE-479 betroffen?

MITRE lists the following affected platforms: C, C++.

Wie kann ich CWE-479 verhindern?

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.

Wie erkennt und behebt Plexicus CWE-479?

Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-479 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-479?

MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/479.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.

Verwandte Schwachstellen

Weaknesses related to CWE-479

CWE-828 Parent

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 Kann vorausgehen

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,…

Ressourcen

Further reading

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.

Kostenlos starten Demo buchen