SIG00-A. Avoid using the same handler for multiple signals

It is possible to safely use the same handler for multiple signals, but doing so increases the likelihood of a security vulnerability. The delivered signal is masked and is not delivered until the registered signal handler exits. However, if this same handler is registered to handle a different signal, execution of the handler may be interrupted by this new signal. If a signal handler is constructed with the expectation that it cannot be interrupted, a vulnerability might exist. To eliminate this attack vector, each signal handler should only be registered to handle one type of signal.

Non-Compliant Coding Example

This non-compliant program registers a single signal handler to process both SIGUSR1 and SIGUSR2. The variable sig2 should be set to one if one or more SIGUSR1 signals are followed by SIGUSR2. a Note that this example violates SIG31-C. Do not access or modify shared objects in signal handlers.

#include <signal.h> 
#include <stdlib.h>
#include <string.h>
 
volatile sig_atomic_t sig1 = 0;
volatile sig_atomic_t sig2 = 0;
 
void handler(int signum) { 
  if (sig1) {
     sig2 = 1;
  }
  sig1 = 1;
} 
 
int main(void) {

  signal(SIGUSR1, handler);
  signal(SIGUSR2, handler);

  /* ... */

  return 0;
}

Risk Assessment

Depending on the code, this could lead to any number of attacks, many of which could give root access. For an overview of some software vulnerabilities, see Zalewski's signal article.

References

[[ISO/IEC 03]] Section 5.2.3, "Signals and interrupts"
[[Open Group 04]] longjmp
[OpenBSD] signal() Man Page
[Zalewski] http://lcamtuf.coredump.cx/signals.txt
[[Dowd 06 ]] Chapter 13, "Synchronization and State" (Signal Interruption and Repetition)