VariantIncompleteCWE-828

CWE-828: Signal Handler with Functionality that is not Asynchronous-Safe

Description

The product defines a signal handler that contains code sequences that are not asynchronous-safe, i.e., the functionality is not reentrant, or it can be interrupted.

Abstraction: VariantA weakness tied to a specific language, technology or resource.
Likelihood of exploit: Not rated by MITRE
Status: Incomplete

Common consequences

IntegrityConfidentialityAvailability
DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands
The most common consequence will be a corruption of the state of the product, possibly leading to a crash or exit. However, if the signal handler is operating on state variables for security relevant libraries or protection mechanisms, the consequences can be far more severe, including protection mechanism bypass...

Potential mitigations

ImplementationArchitecture and DesignEffectiveness: High
Eliminate the usage of non-reentrant functionality inside of signal handlers. This includes replacing all non-reentrant library calls with reentrant calls. Note: This will not always be possible and may require large portions of the product to be rewritten or even redesigned. Sometimes reentrant-safe library alternatives will not be available. Sometimes non-reentrant interaction between the state of the system and the signal handler will be required by design.
Implementation
Where non-reentrant functionality must be leveraged within a signal handler, be sure to block or mask signals appropriately. This includes blocking other signals within the signal handler itself that may also leverage the functionality. It also includes blocking all signals reliant upon the functionality when it is being accessed or modified by the normal behaviors of the product.

Related weaknesses

Parent weaknesses

CWE-364Signal Handler Race Condition

Child weaknesses

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

CAPEC attack patterns that exploit it

CWE 4.20 links no CAPEC attack pattern to this weakness.

Common consequences

IntegrityConfidentialityAvailability

DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands

The most common consequence will be a corruption of the state of the product, possibly leading to a crash or exit. However, if the signal handler is operating on state variables for security relevant libraries or protection mechanisms, the consequences can be far more severe, including protection mechanism bypass...

Potential mitigations

ImplementationArchitecture and DesignEffectiveness: High

Eliminate the usage of non-reentrant functionality inside of signal handlers. This includes replacing all non-reentrant library calls with reentrant calls. Note: This will not always be possible and may require large portions of the product to be rewritten or even redesigned. Sometimes reentrant-safe library alternatives will not be available. Sometimes non-reentrant interaction between the state of the system and the signal handler will be required by design.

Implementation

Where non-reentrant functionality must be leveraged within a signal handler, be sure to block or mask signals appropriately. This includes blocking other signals within the signal handler itself that may also leverage the functionality. It also includes blocking all signals reliant upon the functionality when it is being accessed or modified by the normal behaviors of the product.