CWE-364: Signal Handler Race Condition

Description:
The product uses a signal handler that introduces a race condition.

Extended Description:
Race conditions frequently occur in signal handlers, since signal handlers support asynchronous actions. These race conditions have a variety of root causes and symptoms. Attackers may be able to exploit a signal handler race condition to cause the product state to be corrupted, possibly leading to a denial of service or even code execution. 
             These issues occur when non-reentrant functions, or state-sensitive actions occur in the signal handler, where they may be called at any time. These behaviors can violate assumptions being made by the "regular" code that is interrupted, or by other signal handlers that may also be invoked. If these functions are called at an inopportune moment - such as while a non-reentrant function is already running - memory corruption could occur that may be exploitable for code execution. Another signal race condition commonly found occurs when free is called within a signal handler, resulting in a double free and therefore a write-what-where con

Affected languages: C, C++
Parent weaknesses: CWE-362

Consequences:
  - Integrity: Modify Application Data
  - Access Control: Gain Privileges or Assume Identity

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Requirements] Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  - [Architecture and Design] Design signal handlers to only set flags, rather than perform complex functionality. These flags can then be checked and acted upon within the main program loop.
  - [Implementation] Only use reentrant functions within signal handlers. Also, use validation to ensure that state is consistent while performing asynchronous actions that affect the state of execution.

Demonstrative examples:
This code registers the same signal handler function with two different signals (CWE-831). If those signals are sent to the process, the handler creates a log message (specified in the first argument to the program) and exits.
The handler function uses global state (globalVar and logMessage), and it can be called by both the SIGHUP and SIGTERM signals. An attack scenario might follow these lines:
char *logMessage; 
                      void handler (int sigNum) { 
                         syslog(LOG_NOTICE, "%s\n", logMessage); free(logMessage); 
                            /* artificially increase the size of the timing window to make demonstration of this weakness easier. */ 
                            
                            sleep(10); exit(0); 
                      } 
         

The following code registers a signal handler with multiple signals in order to log when a specific event occurs and to free associated memory before exiting.
However, the following sequence of events may result in a double-free (CWE-415):
#include <signal.h> #include <syslog.h> #include <string.h> #include <stdlib.h> 
                      void *global1, *global2; char *what; void sh (int dummy) { 
                         syslog(LOG_NOTICE,"%s\n",what); free(global2); free(global1); 
                            /* Sleep statements added to expand timing window for race condition */ 
                            
                            sleep(10); exit(0); 
                      } 
                      int main (int argc,char* argv[]) { 
                         what=argv[1]; global1=

Real-world examples:
  - CVE-1999-0035: Signal handler does not disable other signal handlers, allowing it to be interrupted, causing other functionality to access files/etc. with raised privileges
  - CVE-2001-0905: Attacker can send a signal while another signal handler is already running, leading to crash or execution with root privileges
  - CVE-2001-1349: unsafe calls to library functions from signal handler
  - CVE-2004-0794: SIGURG can be used to remotely interrupt signal handler; other variants exist
  - CVE-2004-2259: SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.