Tutorial - Signal Handling Problems

##
Signal Handling Problems

Created 6/1/01

### Impact

It may be possible for a local attacker to execute arbitrary code with root or administrator privileges.

### Background

Signals provide a means of communication between a user and a running process, or between two processes. For example, a `KILL` signal is usually sent to a process to tell it to stop running, and a `HUP` signal is usually sent to a process to tell it to re-initialize itself.

Most programs contain subroutines called signal handlers. Program flow is redirected to the appropriate signal handler whenever the program receives a signal. The signal handler then does any logging, memory de-allocation, or disk cleanup which might be necessary as a result of the signal, before stopping or resuming the program.

### The Problem

Many signal handlers contain system calls which are unsafe because they manipulate global variables. This could lead to unpredictable results if a new signal is sent while a signal handler is already running, or if a signal is sent at a certain point in the execution of the main program. This is known as a race condition. If the signal handler performs an operation which places user-supplied input into memory, such as a logging function, then it may be possible to send a signal or pair of signals which could cause arbitrary code to be executed. Furthermore, if the program contains a signal handler for the `URG` signal, then the condition could be exploited remotely by sending a TCP/IP OOB message, likely causing a denial of service.

The following services are known to be vulnerable to signal handling race conditions:

Sendmail 8.11.3 and earlier
  A local user could execute arbitrary code as root.

### Resolution

Upgrade to a non-vulnerable version of the software:

- Sendmail

### Where can I read more about this?

The theory behind signal handling vulnerabilities was presented in a paper called Delivering Signals for Fun and Profit by BindView.