VariantDraft

CWE-479Signal Handler Use of a Non-reentrant Function

Category: other

Description

The product defines a signal handler that calls a non-reentrant function.

Common consequences· 2

  • Integrity / Confidentiality / Availability — Execute Unauthorized Code or Commands
    It may be possible to execute arbitrary code through the use of a write-what-where condition.
  • Integrity — Modify Memory, Modify Application Data
    Signal race conditions often result in data corruption.

Potential mitigations· 4

  • [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.

References

  1. https://cwe.mitre.org/data/definitions/479.html

Related by meaning· 6

Nearest entities by semantic similarity across the cs-graph corpus.

CWE
Signal Handler with Functionality that is not Asynchronous-Safe
CWE
Use of a Non-reentrant Function in a Concurrent Context
CWE
Signal Handler Race Condition
CWE
Signal Handler Function Associated with Multiple Signals
CWE
Dangerous Signal Handler not Disabled During Sensitive Operations
CWE
Use of Object without Invoking Destructor Method
Sourced from MITRE CWE 4.20. Curated for EU compliance use cases by Adam Lundqvist, Founder at SQUR.