The signal() function has implementation-defined behavior and behaves differently on Windows, for example, on Windows than it does on many Unix UNIX systems.
The following code example illustrates this behavior:
| Code Block |
|---|
#include <stdio.h>
#include <signal.h>
volatile sig_atomic_t e_flag = 0;
void handler(int signum) {
e_flag = 1;
}
int main(void) {
signal(SIGINT, handler);
while (!e_flag) {}
puts("Escaped from first while ()");
e_flag = 0;
while (!e_flag) {}
puts("Escaped from second while ()");
return 0;
}
|
Many Unix UNIX (and UnixUNIX-like) systems automatically reinstall signal handlers upon handler execution, meaning that the signal handler defined by the user is left in place until it is explicitly removed. For example, when this code is compiled with gcc GCC 3.4.4 and executed under Red Hat Linux, the SIGINT is captured both times by handler.
...
When a signal handler is installed with the signal() function in Windows and some Unix UNIX systems, the default action is restored for that signal after the signal is triggered. This means that signal handlers are not automatically reinstalled. For example, when this code is compiled with Microsoft Visual Studio 2005 version 8.0, only the first SIGINT is captured by handler.
...
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, such as when the developer expects the signal handler to persist when but it does not.
Non-Compliant Code Example
This non-compliant code example fails to make the signal handler persist on Windows platforms and on those Unix UNIX systems where handlers are not persistent by default.
...
| Code Block | ||
|---|---|---|
| ||
void handler(int signum) {
signal(signum, handler);
/* Handle 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, thereby defeating the persistent behavior (see \[[SIG34-C. Do not call signal() from within interruptible signal handlers]\]).
A secure solution would prevent the environment from resetting the signal in the first place, and thereby guaranteeing persistence. Unfortunately, Windows does not provide a secure solution to this problem.
...
The POSIX sigaction() function assigns handlers to signals in a manner similar manner to the C99 signal() function , but also allows signal handler persistence to be controlled via the SA_RESETHAND flag. (Leaving the flag clear makes the handler persistent.)
...
Errors may also occur when the developer expects the default action to be restored for a signal , but instead , the signal handler persists.
Non-Compliant Code Example (
...
UNIX)
This non-compliant code example fails to reset the signal handler to its default behavior on those Unix UNIX systems where handlers are persistent by default.
| Code Block | ||
|---|---|---|
| ||
void handler(int signum) {
/* Handle Signal */
}
|
Compliant Solution (
...
UNIX and Windows)
A C99-compliant solution to reset the handler on a Unix UNIX system is to rebind the signal to the default handler in the first line of the handler itself. WhereasWindows, however, Windows automatically resets handlers to default.
| Code Block | ||
|---|---|---|
| ||
void handler(int signum) {
#ifndef WINDOWS
signal(signum, SIG_DFL);
#endif
/* Handle Signal */
}
|
With the Compliant Solution compliant solution for UnixUNIX, there is no race condition that can be exploited by an attacker in sending a second signal. And that is because a second signal sent to the handler, before the latter calls signal(signum, SIG_DFL), will merely cause the handler to restart , and call signal() anyway.
Wiki Markup
Compliant Solution (POSIX)
The POSIX sigaction() function assigns handlers to signals in a manner similar manner to the C99 signal() function , but also allows signal handler persistence to be controlled via the SA_RESETHAND flag. (Setting the flag makes the handler non-persistent.)
...