Signal Handler Use of a Non-reentrant Function

Description

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.

Extended Description

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.

Common Consequences 2

Scope: IntegrityConfidentialityAvailability

Impact: Execute Unauthorized Code or Commands

It may be possible to execute arbitrary code through the use of a write-what-where condition.

Scope: Integrity

Impact: Modify MemoryModify Application Data

Signal race conditions often result in data corruption.

Detection Methods 1

Automated Static AnalysisHigh

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

Potential Mitigations 4

Phase: Requirements

Require languages or libraries that provide reentrant functionality, or otherwise make it easier to avoid this weakness.

Phase: Architecture and Design

Design signal handlers to only set flags rather than perform complex functionality.

Phase: Implementation

Ensure that non-reentrant functions are not found in signal handlers.

Phase: 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.

Effectiveness: Defense in Depth

Demonstrative Examples 1

ID : DX-171

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

Code Example:Bad
C
c

Observed Examples 2

CVE-2005-0893signal handler calls function that ultimately uses malloc()

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

References 2

The CLASP Application Security Process

Secure Software, Inc.

2005

https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf(2024-11-17)

ID: REF-18

The Art of Software Security Assessment

Mark Dowd, John McDonald, and Justin Schuh

Addison Wesley

2006

ID: REF-62

Likelihood of Exploit

Low

Applicable Platforms

Languages:

C : UndeterminedC++ : Undetermined

Modes of Introduction

Implementation

Affected Resources

System Process

Related Weaknesses

ChildOf:

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

ChildOf:

Use of a Non-reentrant Function in a Concurrent Context (CWE-663)

CanPrecede:

Write-what-where Condition (CWE-123)

Taxonomy Mapping

CLASP
CERT C Secure Coding
CERT C Secure Coding
The CERT Oracle Secure Coding Standard for Java (2011)
Software Fault Patterns