Signal Handling Problems
Created 6/1/01
CVE 2001-1349
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:
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.