The signal() function has implementation-defined behavior and behaves differently, for example, on Windows than it does on Unix systems.
The following code example code illustrates this behavior:
...
Different actions must be taken depending on whether or not the application requires signal handlers to be persistent.
Non-Persistent Handlers
Errors and potential vulnerabilities exist when the actual Asynchronous signals may originate from potentially hostile sources outside the process. Consequently, vulnerabilities may exist in cases where the signal handler persistence behavior is inconsistent with the developer's expectations, for example, the developer expects the signal handler to persist but when it does not. This is due to the possibility of asynchronous signals arising from outside the program, potentially from hostile sources.
Non-Compliant Code Example (Windows)
...
Non-Compliant Code Example (Windows)
A common solution to make create persistent signal handlers is to call signal() inside from within the handler itself, thus 'consequently unresetting' the reset signal.
| Code Block | ||
|---|---|---|
| ||
void handler(int signum) {
#ifdef WINDOWS
signal(signum, handler);
#endif
/* handling code */
}
|
Unfortunately this solution still permits contains a race window. , starting when the OS first host environment resets the signal , and ending when the handler calls signal(). During that time, a second signal sent to the program will still trigger the default signal behavior, thereby destroying persistencedefeating the persistent behavior.
A secure solution would prevent the OS from resetting the signal in the first place, and thereby guarantee persistence. Unfortunately, Windows does not provide a secure solution to this problem.
...