Description
The software defines a signal handler that contains code sequences that are not asynchronous-safe, i.e., the functionality is not reentrant, or it can be interrupted.
Modes of Introduction:
Likelihood of Exploit:
Related Weaknesses
Consequences
Integrity, Confidentiality, Availability: DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands
The most common consequence will be a corruption of the state of the software, possibly leading to a crash or exit. However, if the signal handler is operating on state variables for security relevant libraries or protection mechanisms, the consequences can be far more severe, including protection mechanism bypass, privilege escalation, or information exposure.
Potential Mitigations
Phase: Implementation, Architecture and Design
Effectiveness: High
Description:
Phase: Implementation
Effectiveness:
Description:
Where non-reentrant functionality must be leveraged within a signal handler, be sure to block or mask signals appropriately. This includes blocking other signals within the signal handler itself that may also leverage the functionality. It also includes blocking all signals reliant upon the functionality when it is being accessed or modified by the normal behaviors of the software.
CVE References
- CVE-2008-4109
- Signal handler uses functions that ultimately call the unsafe syslog/malloc/s*printf, leading to denial of service via multiple login attempts
- CVE-2006-5051
- Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
- 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.
- CVE-2002-1563
- SIGCHLD not blocked in a daemon loop while counter is modified, causing counter to get out of sync.