This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Unsafe function call from a signal handler"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 +
{{Template:Vulnerability}}
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
==Overview==
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
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.
+
[[ASDR Table of Contents]]
 +
__TOC__
  
==Consequences ==
 
  
* Access control: It may be possible to execute arbitrary code through the use of a write-what-where condition.
+
==Description==
  
* Integrity: Signal race conditions often result in data corruption.
+
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.
  
==Exposure period ==
+
'''Consequences'''
  
* Requirements specification: A language might be chosen which is not subject to this flaw.
+
* 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.
  
* Design: Signal handlers with complicated functionality may result in this issue.
+
'''Exposure period'''
  
* Implementation: The use of any number of non-reentrant functions will result in this issue.
+
* Requirements specification: A language might be chosen which is not subject to this flaw.
 +
* Design: Signal handlers with complicated functionality may result in this issue.
 +
* Implementation: The use of any number of non-reentrant functions will result in this issue.
  
==Platform ==
+
'''Platform'''
  
* Languages: C, C++, Assembly
+
* Languages: C, C++, Assembly
 +
* Platforms: All
  
* Platforms: All
+
'''Required resources'''
 
 
==Required resources ==
 
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
Low
 
Low
  
==Avoidance and mitigation ==
+
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.
 +
 
 +
 
 +
==Risk Factors==
 +
 
 +
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
 +
* Discuss the technical impact of a successful exploit of this vulnerability
 +
* Consider the likely [business impacts] of a successful attack
 +
 
 +
 
 +
==Examples==
 +
 
 +
See ''Race condition in signal handler'', for an example usage of free() in a signal handler which is exploitable.
 +
 
 +
 
 +
==Related [[Attacks]]==
 +
 
 +
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
  
* Requirements specification: A language might be chosen, which is not subject to this flaw, through a guarantee of reentrant code.
+
* [[Race condition in signal handler]]
 +
* [[Write-what-where condition]]
  
* Design: Design signal handlers to only set flags rather than perform complex functionality.
 
  
* 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.
 
  
==Discussion ==
+
==Related [[Controls]]==
  
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.
+
* Requirements specification: A language might be chosen, which is not subject to this flaw, through a guarantee of reentrant code.
 +
* Design: Design signal handlers to only set flags rather than perform complex functionality.
 +
* 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.
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
 
 +
TBD
 +
[[Category:FIXME|add links
 +
 
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 
 +
Availability Vulnerability
 +
 
 +
Authorization Vulnerability
 +
 
 +
Authentication Vulnerability
 +
 
 +
Concurrency Vulnerability
 +
 
 +
Configuration Vulnerability
 +
 
 +
Cryptographic Vulnerability
  
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.
+
Encoding Vulnerability
  
==Examples ==
+
Error Handling Vulnerability
  
See ''Race condition in signal handler'', for an example usage of free() in a signal handler which is exploitable.
+
Input Validation Vulnerability
  
==Related problems ==
+
Logging and Auditing Vulnerability
  
* [[Race condition in signal handler]]
+
Session Management Vulnerability]]
  
* [[Write-what-where condition]]
+
__NOTOC__
  
  
 +
[[Category:OWASP ASDR Project]]
 
[[Category:Use of Dangerous API]]
 
[[Category:Use of Dangerous API]]
 
[[Category:Synchronization and Timing Vulnerability]]
 
[[Category:Synchronization and Timing Vulnerability]]
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]

Revision as of 13:22, 3 October 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

Last revision (mm/dd/yy): 10/3/2008

Vulnerabilities Table of Contents

ASDR Table of Contents


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.

Consequences

  • 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.

Exposure period

  • Requirements specification: A language might be chosen which is not subject to this flaw.
  • Design: Signal handlers with complicated functionality may result in this issue.
  • Implementation: The use of any number of non-reentrant functions will result in this issue.

Platform

  • Languages: C, C++, Assembly
  • Platforms: All

Required resources

Any

Severity

High

Likelihood of exploit

Low

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.


Risk Factors

  • Talk about the factors that make this vulnerability likely or unlikely to actually happen
  • Discuss the technical impact of a successful exploit of this vulnerability
  • Consider the likely [business impacts] of a successful attack


Examples

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


Related Attacks


Related Vulnerabilities


Related Controls

  • Requirements specification: A language might be chosen, which is not subject to this flaw, through a guarantee of reentrant code.
  • Design: Design signal handlers to only set flags rather than perform complex functionality.
  • 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.


Related Technical Impacts


References

TBD