Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Do not call non-reentrant functions within signal handlers. This could result in several issues, including heap damage and semantic vulnerabilities.

According to the "Signals and Interrupts" section of the C99 Rationale:

When a signal occurs, the normal flow of control of a program is interrupted. If a signal occurs that is being trapped by a signal handler, that handler is invoked. When it is finished, execution continues at the point at which the signal occurred. This arrangement could cause problems if the signal handler invokes a library function that was being executed at the time of the signal. Since library functions are not guaranteed to be reentrant, they should not be called from a signal handler that returns.

Implementation Details

The OpenBSD signal() man page identifies functions that are either reentrant or not interruptible by signals and are asynchronous-signal safe. Applications may therefore invoke them, without restriction, from signal-catching functions.

Non-Compliant Code Example

This non-compliant code example invokes the longjmp function to transfer control from the signal handler int_handler() back into main(). Once control returns to main(), a potentially non-reentrant system call is made to strcpy(). Using the longjmp function inside a signal handler is particularly dangerous, as it could call any part of your code.

#include <setjmp.h> 
#include <signal.h> 
 
static jmp_buf env; 
 
void int_handler() { 
  longjmp(env, 1); 
  return;
} 
 
int main(void) { 
  char *foo; 

  signal(SIGINT, int_handler); 
 
  if (setjmp(env) == 0) { 
    foo = malloc(15);
    strcpy(foo, "Nothing yet.");
  }
  else {
    strcpy(foo, "Signal caught.");
  }

  /* main loop which displays foo */

  return 0;
}

Compliant Solution

Signal handlers should be as minimal as possible, only unconditionally setting a flag where appropriate, and returning.

#include <signal.h> 

int interrupted = 0;
 
void int_handler() { 
  interrupted = 1;
  return;
} 
 
int main(void) { 
  char *foo; 

  signal(SIGINT, int_handler); 
    
  foo = malloc(15);
  strcpy(foo, "Nothing yet.");
  
  /* main loop which displays foo */
  if (interrupted == 1) {
    strcpy(foo, "Signal caught.");
  }

  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. VU #834865 is also an example of this.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SIG00-C

3 (high)

3 (likely)

1 (high)

P9

L2

References

[[ISO/IEC 03]] "Signals and Interrupts"
[[Open Group 04]] longjmp
[OpenBSD] signal() Man Page
[Zalewski 01] http://lcamtuf.coredump.cx/signals.txt

  • No labels