CWE-364: Signal Handler Race Condition

Requirements

Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Architecture and Design

Design signal handlers to only set flags, rather than perform complex functionality. These flags can then be checked and acted upon within the main program loop.

Implementation

Only use reentrant functions within signal handlers. Also, use validation to ensure that state is consistent while performing asynchronous actions that affect the state of execution.

IntegrityConfidentialityAvailabilityModify Application DataModify MemoryDoS: Crash, Exit, or RestartExecute Unauthorized Code or Commands

It may be possible to cause data corruption and possibly execute arbitrary code by modifying global variables or data structures at unexpected times, violating the assumptions of code that uses this global data.

Access ControlGain Privileges or Assume Identity

If a signal handler interrupts code that is executing with privileges, it may be possible that the signal handler will also be executed with elevated privileges, possibly making subsequent exploits more severe.

Automated Static Analysis

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-364

Signal Handler Race Condition

Potential Mitigations (3)

Common Consequences (2)

Detection Methods (1)

Modes of Introduction

Related Weaknesses

Example CVEs (5)

External Links