Unsafe Function Call from a Signal Handler
Weakness ID: 479 (Weakness Variant)Status: Draft
+ Description

Description Summary

The program has a signal handler that calls an unsafe function, leading to unpredictable results.

Extended Description

There are several functions which -- under certain circumstances, if used in a signal handler -- may result in the corruption of memory, allowing for exploitation of the process.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Access Control

It may be possible to execute arbitrary code through the use of a write-what-where condition.

Integrity

Signal race conditions often result in data corruption.

+ Likelihood of Exploit

Low

+ Demonstrative Examples

Example 1

See Signal handler race condition, for an example usage of free() in a signal handler which is exploitable.

+ Potential Mitigations

Requirements specification: A language might be chosen, which is not subject to this flaw, through a guarantee of reentrant code.

Phase: Architecture and Design

Design signal handlers to only set flags rather than perform complex functionality.

Phase: Implementation

Ensure that non-reentrant functions are not found in signal handlers. Also, use sanity checks to ensure that state is consistently performing asynchronous actions which effect the state of execution.

+ Other Notes

This flaw is a subset of race conditions occurring in signal handler calls which is concerned primarily with memory corruption caused by calls to non-reentrant functions in signal handlers. Non-reentrant functions are functions that cannot safely be called, interrupted, and then recalled before the first call has finished without resulting in memory corruption. The function call syslog() is an example of this. In order to perform its functionality, it allocates a small amount of memory as "scratch space." If syslog() is suspended by a signal call and the signal handler calls syslog(), the memory used by both of these functions enters an undefined, and possibly, exploitable state.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Development Concepts (primary)699
ChildOfCategoryCategory429Handler Errors
Development Concepts699
ChildOfCategoryCategory634Weaknesses that Affect System Processes
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class691Insufficient Control Flow Management
Research Concepts (primary)1000
ChildOfCategoryCategory745CERT C Secure Coding Section 11 - Signals (SIG)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
PeerOfWeakness BaseWeakness Base123Write-what-where Condition
Research Concepts1000
PeerOfWeakness BaseWeakness Base364Signal Handler Race Condition
Research Concepts1000
+ Affected Resources
  • System Process
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPUnsafe function call from a signal handler
CERT C Secure CodingSIG30-CCall only asynchronous-safe functions within signal handlers
CERT C Secure CodingSIG32-CDo not call longjmp() from inside a signal handler
CERT C Secure CodingSIG33-CDo not recursively invoke the raise() function
CERT C Secure CodingSIG34-CDo not call signal() from within interruptible signal handlers
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable Platforms, Common Consequences, Description, Relationships, Other Notes, Taxonomy Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy Mappings
Back to top