Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

A signal is a mechanism for transferring control that is typically used to notify a process that an event has occurred. That process can then respond to the event accordingly. The C Standard provides functions for sending and handling signals within a C program.

Processes handle signals by registering a signal handler using the signal() function, which is specified as

Code Block
void (*signal(int sig, void (*func)(int)))(int);

This signal handler is conceptually equivalent to

Code Block
typedef void (*sighandler_t)(int signum);
extern sighandler_t signal(
  int signum, 
  sighandler_t handler
);

Signal handlers can be interrupted by signals, including their own signals. If a signal is not reset before its handler is called, this means the handler can essentially 'interrupt itself'interrupt its own execution. A handler that always successfully executes its code despite interrupting itself is said to be re-entrantor being interrupted is async-signal-safe.

Some platforms provide the ability to mask signals while a signal handler is being processed. If a signal is masked while its own handler is processed, the handler is un-interruptible, noninterruptible and need not be re-entrantasync-signal-safe. However, even when a signal is masked while its own handler is processed, the handler must still avoid invoking async-signal-safe unsafe functions because their execution may be (or have been) interrupted by another signal.

Vulnerabilities can arise if a non-re-entrant signal handler signal handler that is not async-signal-safe is interrupted with any unmasked signal, including its own signal, especially if it manipulates globally-accessible data.

...

Noncompliant Code Example

This non-compliant program noncompliant code example registers a single signal handler to process both SIGUSR1 and SIGUSR2. The variable sig2 should be set to one 1 if one or more SIGUSR1 signals are followed by SIGUSR2. This code , essentially implements implementing a finite state machine within the signal handler.

Code Block
bgColor#FFcccc
langc

#include <signal.h>

volatile sig_atomic_t sig1 = 0;
volatile sig_atomic_t sig2 = 0;

void handler(int signum) {
  if (signum == SIGUSR1) {
    sig1 = 1;
  }
  else if (sig1) {
     sig2 = 1;
  }
}

int main(void) {
  if (signal(SIGUSR1, handler);
  signal(SIGUSR2, handler);

  while (sig2 == 0SIG_ERR) {
    /* doHandle nothing or give up CPU for a while error */
  }

  /* ... */

  return 0;
}

The problem with this code is that there is a race condition in the implementation of handler(). If handler() is called to handle SIGUSR1 and is interrupted to handle SIGUSR2, it is possible that sig2 will not be set.

This non-compliant code example also violates SIG31-C. Do not access or modify shared objects in signal handlers.

Compliant Solution

This compliant solution moves the finite state machine out of the signal handler, making it re-entrant.

Code Block
bgColor#ccccff

#include <signal.h>

volatile sig_atomic_t sig1 = 0;
volatile sig_atomic_t sig2 = 0;

void handler(int signum) {
  if (signum == SIGUSR1if (signal(SIGUSR2, handler) == SIG_ERR) {
    /* sig1Handler =error 1;*/
  }

  elsewhile if (signum == SIGUSR2) {
    sig2 = 1;
  }
}

int main(void) {
  int state = 0;
  signal(SIGUSR1, handler);
  signal(SIGUSR2, handler);

  while (state != 2) {
    /* doDo nothing or give up CPU for a while */
    if (state == 0 && sig1) {
      state = 1;
    }
    if (state == 1 && sig2) {
      state = 2;
    }
  }

  /* ... */

  return 0;
}

Unfortunately, a race condition occurs in the implementation of handler(). If handler() is called to handle SIGUSR1 and is interrupted to handle SIGUSR2, it is possible that sig2 will not be set.

Compliant Solution (POSIX)

The POSIX defines the sigaction(2) function , which assigns handlers to signals like in a similar manner to the C signal(2) function, but it also allows one signal masks to be set explicitly set signal masks. One can thus use . Consequently, sigaction(2) and can be used to prevent a signal handler from interrupting itself.

Code Block
bgColor#ccccff
langc

#include <signal.h>
#include <stdio.h>

volatile sig_atomic_t sig1 = 0;
volatile sig_atomic_t sig2 = 0;

void handler(int signum) {
  if (signum == SIGUSR1) {
    sig1 = 1;
  }
  else if (sig1) {
    sig2 = 1;
  }
}

int main(void) {
  struct sigaction act;
  act.sa_handler = &handler;
  act.sa_flags = 0;
  if (sigfillsetsigemptyset( &act.sa_mask) != 0) {
    /* handleHandle error */
  }
  if (sigdelsetsigaddset( &act.sa_mask, SIGUSR1)) {
    /* handleHandle error */
  }
  if (sigdelsetsigaddset( &act.sa_mask, SIGUSR2)) {
    /* handleHandle error */
  }

  if (sigaction(SIGUSR1, &act, NULL) != 0) {
    /* handleHandle error */
  }
  if (sigaction(SIGUSR2, &act, NULL) != 0) {
    /* handleHandle error */
  }

  while (sig2 == 0) {
    /* doDo nothing or give up CPU for a while */
  }

  /* ... */

  return 0;
}

In fact, POSIX recommends sigaction(2) and deprecates the use of signal(2) to register signal handlers. Unfortunately, sigaction(2) is not defined in the C Standard and is not C99-compliantconsequently not as portable a solution.

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 articleInterrupting a noninterruptible signal handler can result in a variety of vulnerabilities [Zalewski 2001].

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

SIG00-

A

3 (high)

3 (likely)

1 (high)

C

High

Likely

High

P9

L2

Automated Detection

Tool

Version

Checker

Description

CodeSonar
Include Page
CodeSonar_V
CodeSonar_V
BADFUNC.SIGNALUse of signal
Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C5019
LDRA tool suite
Include Page
LDRA_V
LDRA_V
44 SEnhanced enforcement
Parasoft C/C++test
Include Page
Parasoft_V
Parasoft_V
CERT_C-SIG00-a

The signal handling facilities of <signal.h> shall not be used

PC-lint Plus

Include Page
PC-lint Plus_V
PC-lint Plus_V

586

Assistance provided: reports use of the signal function

Related Vulnerabilities

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

References

...

Related Guidelines

Bibliography

[C99 Rationale 2003]Subclause

...

5.2.3,

...

"Signals

...

and

...

Interrupts"
[Dowd 2006]Chapter 13, "Synchronization and State" ("Signal Interruption and Repetition")
[IEEE Std 1003.1:2013]XSH, System Interface, longjmp
[OpenBSD]signal() Man Page
[Zalewski 2001]"Delivering Signals for Fun and Profit"


...

Image Added Image Added Image Added \[[Open Group 04|AA. C References#Open Group 04]\] [longjmp|http://www.opengroup.org/onlinepubs/000095399/functions/longjmp.html] \[OpenBSD\] [{{signal()}} Man Page|http://www.openbsd.org/cgi-bin/man.cgi?query=signal] \[Zalewski\] [http://lcamtuf.coredump.cx/signals.txt] \[[Dowd 06 | AA. C References#Dowd 06]\] Chapter 13, "Synchronization and State" (Signal Interruption and Repetition)12. Signals (SIG)      12. Signals (SIG)       SIG01-A. Understand implementation-specific details regarding signal handler persistence