Page History

...

Asynchronous signals may originate from malicious actors external to the process. Consequently, vulnerabilities may exist if the signal-handler-persistence behavior is inconsistent with the developer's expectations, such as when the developer expects the signal handler to persist but it does not.

...

A common approach to create persistent signal handlers is to call signal() from within the handler itself, consequently , unresetting the reset signal:

...

/* 
 * Equivalent to signal(SIGUSR1, handler) but makes
 * signal persistent. 
 */
struct sigaction act;
act.sa_handler = handler;
act.sa_flags = 0;
if (sigemptyset(&act.sa_mask) != 0) {
  /* Handle error */
}
if (sigaction(SIGUSR1, &act, NULL) != 0) {
  /* Handle error */
}

...

With the compliant solution for UNIX, no race condition occurs that can be exploited by an attacker sending a second signal. This is because a second signal sent to the handler, before the latter calls signal(signum, SIG_DFL), will only cause the handler to restart and call signal() anyway.

...

/* 
 * Equivalent to signal(SIGUSR1, handler) but makes
 * signal nonpersistent .
 */
struct sigaction act;
act.sa_handler = handler;
act.sa_flags = SA_RESETHAND;
if (sigemptyset(&act.sa_mask) != 0) {
  /* Handle error */
}
if (sigaction(SIGUSR1, &act, NULL) != 0) {
  /* Handle error */
}

...

Failure to understand implementation-specific details regarding signal-handler persistence can lead to unexpected behavior.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

...

...

Image Modified Image Modified Image Modified