...
A common approach to create persistent signal handlers is to call signal() from within the handler itself, consequently, unresetting the reset signal.
...
Unfortunately, this solution still contains a race window, starting when the host environment resets the signal and ending when the handler calls signal(). During that time, a second signal sent to the program will trigger the default signal behavior, defeating the persistent behavior. (see See rule SIG34-C. Do not call signal() from within interruptible signal handlers.).
A secure solution must prevent the environment from resetting the signal in the first place, guaranteeing persistence. Unfortunately, Windows does not provide a secure solution to this problem.
...
This solution is an exception to rule SIG34-C. Do not call signal() from within interruptible signal handlers.
...
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
SIG01-C | low | unlikely | low | P3 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||
|---|---|---|---|---|---|---|---|
|
|
|
|
...
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Other Languages
Related Guidelines
CERT This rule appears in the C++ Secure Coding Standard as : SIG01-CPP. Understand implementation-specific details regarding signal handler persistence.
Bibliography
unmigrated-wiki-markup
\[[ISO/IEC 9899-1999TR2|AA. Bibliography#ISO/IEC 9899-1999]\] Section 7.14.1.1, "The {{signal}} function"
Bibliography
...