"Delivering Signals for Fun and Profit"
Understanding, exploiting and preventing signal-handling
Michal Zalewski <firstname.lastname@example.org>
(C) Copyright 2001 BindView Corporation
According to a popular belief, writing signal handlers has little or nothing
to do with secure programming, as long as handler code itself looks good.
At the same time, there have been discussions on functions that shall be
invoked from handlers, and functions that shall never, ever be used there.
Most Unix systems provide a standarized set of signal-safe library calls.
Few systems have extensive documentation of signal-safe calls - that includes
OpenBSD, Solaris, etc.:
"The following functions are either reentrant or not interruptible by sig-
nals and are async-signal safe. Therefore applications may invoke them,
without restriction, from signal-catching functions:
_exit(2), access(2), alarm(3), cfgetispeed(3), cfgetospeed(3),
cfsetispeed(3), cfsetospeed(3), chdir(2), chmod(2), chown(2),
close(2), creat(2), dup(2), dup2(2), execle(2), execve(2),
fcntl(2), fork(2), fpathconf(2), fstat(2), fsync(2), getegid(2),
geteuid(2), getgid(2), getgroups(2), getpgrp(2), getpid(2),
getppid(2), getuid(2), kill(2), link(2), lseek(2), mkdir(2),
mkfifo(2), open(2), pathconf(2), pause(2), pipe(2), raise(3),
read(2), rename(2), rmdir(2), setgid(2), setpgid(2), setsid(2),
setuid(2), sigaction(2), sigaddset(3), sigdelset(3),
sigemptyset(3), sigfillset(3), sigismember(3), signal(3),
sigpending(2), sigprocmask(2), sigsuspend(2), sleep(3), stat(2),
sysconf(3), tcdrain(3), tcflow(3), tcflush(3), tcgetattr(3),
tcgetpgrp(3), tcsendbreak(3), tcsetattr(3), tcsetpgrp(3), time(3),
times(3), umask(2), uname(3), unlink(2), utime(3), wait(2),
waitpid(2), write(2). sigpause(3), sigset(3).
All functions not in the above list are considered to be unsafe with re-
spect to signals. That is to say, the behaviour of such functions when
called from a signal handler is undefined. In general though, signal
handlers should do little more than set a flag; most other actions are
It is suggested to take special care when performing any non-atomic
operations while signal delivery is not blocked, and/or not to rely on
internal program state in signal handler. Generally, signal handlers should
do not much more than setting a flag, whenever it is acceptable.
Unfortunately, there were no known, practical security considerations of
such bad coding practices. And while signal can be delivered _anywhere_
during the userspace execution of given program, most of programmers never
take enough care to avoid potential implications caused by this fact.
Approximately 80 to 90% of signal handlers we have examined were written
in insecure manner.
This paper is an attempt to demonstrate and analyze actual risks caused by
this kind of coding practices, and to discuss threat scenarios that can be
used by an attacker in order to escalate local privileges, or, sometimes,
gain remote access to a machine. This class of vulnerabilities affects
numerous complex setuid programs (Sendmail, screen, pppd, etc.) and
several network daemons (ftpd, httpd and so on).
Thanks to Theo de Raadt for bringing this problem to my attention;
to Przemyslaw Frasunek for remote attack possibilities discussion; Dvorak,
Chris Evans and Pekka Savola for outstanding contribution to heap corruption
attacks field; Gregory Neil Shapiro and Solar Designer for their comments
on the issues discussed below. Additional thanks to Mark Loveless,
Dave Mann, Matt Power and other RAZOR team members for their support and
첨부 파일: signals.txt (20 KiB(20,738 Bytes))
[분류: 리눅스 ]