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).
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.:
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.