What is Signal Handler Use of a Non-reentrant (CWE-479)?

TL;DR: Signal Handler Use of a Non-reentrant Function (CWE-479) is a vulnerability where non-thread-safe functions are called in signal handlers, leading to potential race conditions and data corruption. To fix it, ensure signal handlers only set flags or use reentrant functions.

What is Signal Handler Use of a Non-reentrant Function?

Signal Handler Use of a Non-reentrant Function (CWE-479) is a type of vulnerability that occurs when signal handlers in software invoke functions not designed for concurrent execution. As defined by the MITRE Corporation under CWE-479, and classified by the OWASP Foundation as it has no direct mapping.

Quick Summary

Signal Handler Use of a Non-reentrant Function allows attackers to exploit race conditions caused by non-thread-safe function calls within signal handlers. This can lead to data corruption or unauthorized code execution. Jump to: Overview · How It Works · Business Impact · Attack Scenario · Detection · Fixing · Framework Fixes · Asking AI · Best Practices · FAQ · Related Vulnerabilities

Jump to: Quick Summary · Signal Handler Use of a Non-reentrant Function Overview · How Signal Handler Use of a Non-reentrant Function Works · Business Impact of Signal Handler Use of a Non-reentrant Function · Signal Handler Use of a Non-reentrant Function Attack Scenario · How to Detect Signal Handler Use of a Non-reentrant Function · How to Fix Signal Handler Use of a Non-reentrant Function · Framework-Specific Fixes for Signal Handler Use of a Non-reentrant Function · How to Ask AI to Check Your Code for Signal Handler Use of a Non-reentrant Function · Signal Handler Use of a Non-reentrant Function Best Practices Checklist · Signal Handler Use of a Non-reentrant Function FAQ · Vulnerabilities Related to Signal Handler Use of a Non-reentrant Function · References · Scan Your Own Site

Signal Handler Use of a Non-reentrant Function Overview

What: A vulnerability where signal handlers call non-thread-safe functions, leading to race conditions and data corruption.

Why it matters: It can cause system crashes, unexpected behavior, or unauthorized code execution due to improper handling of signals.

Where it occurs: In applications that use signal handlers with non-reentrant function calls in C/C++/Python/Java environments.

Who is affected: Developers using languages where signal handlers are implemented and who rely on third-party libraries without reentrancy guarantees.

Who is NOT affected: Applications that exclusively use thread-safe functions or those employing proper synchronization mechanisms within their signal handlers.

How Signal Handler Use of a Non-reentrant Function Works

Root Cause

The root cause lies in the invocation of non-thread-safe functions from within signal handlers. These functions are not designed to handle concurrent execution, leading to race conditions and potential data corruption.

Attack Flow

1. An attacker triggers a signal that is handled by a handler.
2. The handler invokes a non-reentrant function.
3. Race condition occurs due to simultaneous access or modification of shared resources.
4. Data corruption or arbitrary code execution may result.

Prerequisites to Exploit

• Signal handlers must call non-thread-safe functions without proper synchronization mechanisms.
• Shared resources accessed by the non-reentrant function must be concurrently modifiable.

Vulnerable Code

#include <signal.h>
void handler(int sig) {
    printf("Signal received: %d\n", sig);
}

This code is vulnerable because it uses printf, which may not be reentrant. The absence of synchronization mechanisms makes it susceptible to race conditions when signals are handled concurrently.

Secure Code

#include <signal.h>
void handler(int sig) {
    volatile int flag = 1;
    // Set flags instead of performing complex operations
}

The secure code avoids calling non-reentrant functions and only sets flags within the signal handler, ensuring thread safety and avoiding race conditions.

Business Impact of Signal Handler Use of a Non-reentrant Function

Confidentiality: Data may be exposed due to improper handling leading to unauthorized access or data leaks. Integrity: Race conditions can corrupt application data, affecting its integrity. Availability: System crashes or unexpected behavior can disrupt service availability.

• Financial loss from system downtime
• Compliance violations due to data breaches
• Reputation damage from security incidents

Signal Handler Use of a Non-reentrant Function Attack Scenario

1. Attacker triggers a signal that is handled by the vulnerable handler.
2. The non-thread-safe function within the handler causes race conditions.
3. Data corruption or unauthorized code execution occurs, leading to system instability.

How to Detect Signal Handler Use of a Non-reentrant Function

Manual Testing

• Review signal handlers for calls to non-thread-safe functions.
• Ensure proper synchronization mechanisms are in place.

- [ ] Identify signal handler definitions and their associated functions.
- [ ] Check if any called functions are known to be non-reentrant or lack thread safety guarantees.

Automated Scanners (SAST / DAST)

Static analysis tools can detect calls to non-thread-safe functions within signal handlers, while dynamic testing may reveal race conditions during runtime.

PenScan Detection

PenScan’s scanner engines like ZAP and Wapiti identify potential CWE-479 issues by analyzing code patterns for non-reentrant function usage in signal handlers.

False Positive Guidance

False positives occur when a non-thread-safe function is called but properly synchronized to avoid race conditions. Ensure that any flagged functions are indeed called without proper synchronization mechanisms.

How to Fix Signal Handler Use of a Non-reentrant Function

• Design signal handlers to only set flags rather than perform complex functionality.
• Ensure that non-reentrant functions are not found in signal handlers.
• Use sanity checks to reduce the timing window for exploitation of race conditions.

Framework-Specific Fixes for Signal Handler Use of a Non-reentrant Function

C/C++

Ensure signal handlers do not call non-thread-safe functions and only set flags or use thread-safe alternatives.

#include <signal.h>
void handler(int sig) {
    volatile int flag = 1;
}

How to Ask AI to Check Your Code for Signal Handler Use of a Non-reentrant Function

Signal Handler Use of a Non-reentrant Function Best Practices Checklist

✅ Design signal handlers to only set flags rather than perform complex functionality. ✅ Ensure non-reentrant functions are not invoked within signal handlers. ✅ Implement proper synchronization mechanisms to mitigate race conditions.

Signal Handler Use of a Non-reentrant Function FAQ

How does Signal Handler Use of a Non-reentrant Function occur?

It occurs when a signal handler calls a function that is not designed for concurrent execution, leading to potential race conditions and data corruption.

What are the consequences of Signal Handler Use of a Non-reentrant Function?

It can lead to arbitrary code execution and data integrity issues due to race conditions in signal handling routines.

How do I detect Signal Handler Use of a Non-reentrant Function?

Detect it through static analysis tools that identify non-reentrant function calls within signal handlers, or by manually reviewing the code for such patterns.

What is an example of vulnerable code for Signal Handler Use of a Non-reentrant Function?

A signal handler calling a non-reentrant library function without proper synchronization mechanisms can cause race conditions and data corruption.

How do I fix Signal Handler Use of a Non-reentrant Function in my application?

Design signal handlers to only set flags rather than perform complex functionality, or ensure that any called functions are reentrant and thread-safe.

What is the impact of Signal Handler Use of a Non-reentrant Function on system availability?

It can disrupt system availability by causing crashes or unexpected behavior due to race conditions in signal handling routines.

How do I prevent Signal Handler Use of a Non-reentrant Function during development?

Avoid using non-reentrant functions within signal handlers and opt for reentrant alternatives that are designed for concurrent execution.

Vulnerabilities Related to Signal Handler Use of a Non-reentrant Function

References

• MITRE - CWE-479
• NVD NIST

Scan Your Own Site

Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find Signal Handler Use of a Non-reentrant Function and other risks before an attacker does.