Difference between revisions of "Stack overflow"

From OWASP
Jump to: navigation, search
 
(2 intermediate revisions by one user not shown)
Line 1: Line 1:
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR Table of Contents]]
 
__TOC__
 
  
  
 
==Description==
 
==Description==
 
 
A stack overflow condition is a buffer overflow condition, where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
 
A stack overflow condition is a buffer overflow condition, where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
  

Latest revision as of 15:58, 28 February 2009

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



Last revision (mm/dd/yy): 02/28/2009

Vulnerabilities Table of Contents


Description

A stack overflow condition is a buffer overflow condition, where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).

Consequences

  • Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
  • Access control (memory and instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.
  • Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

Exposure period

  • Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
  • Design: Mitigating technologies such as safe string libraries and container abstractions could be introduced.
  • Implementation: Many logic errors can lead to this condition. It can be exacerbated by lack of or misuse of mitigating technologies.

Platform

  • Languages: C, C++, Fortran, Assembly
  • Operating platforms: All, although partial preventative measures may be deployed depending on environment.

Required resources

Any

Severity

Very high

Likelihood of exploit

Very high

There are generally several security-critical data on an execution stack that can lead to arbitrary code execution. The most prominent is the stored return address, the memory address at which execution should continue once the current function is finished executing. The attacker can overwrite this value with some memory address to which the attacker also has write access, into which he places arbitrary code to be run with the full privileges of the vulnerable program.

Alternately, the attacker can supply the address of an important call, for instance the POSIX system() call, leaving arguments to the call on the stack. This is often called a return into libc exploit, since the attacker generally forces the program to jump at return time into an interesting routine in the C standard library (libc).

Other important data commonly on the stack include the stack pointer and frame pointer, two values that indicate offsets for computing memory addresses. Modifying those values can often be leveraged into a "write-what-where" condition.


Risk Factors

TBD


Examples

While the buffer overflow example above counts as a stack overflow, it is possible to have even simpler, yet still exploitable, stack based buffer overflows:

#define BUFSIZE 256

int main(int argc, char **argv) {
  char buf[BUFSIZE];

  strcpy(buf, argv[1]);
}


Related Attacks


Related Vulnerabilities


Related Controls

  • Pre-design: Use a language or compiler that performs automatic bounds checking.
  • Design: Use an abstraction library to abstract away risky APIs. Not a complete solution.
  • Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio / GS flag. Unless this provides automatic bounds checking, it is not a complete solution.
  • Operational: Use OS-level preventative functionality. Not a complete solution.


Related Technical Impacts


References

Note: A reference to related CWE or CAPEC article should be added when exists. Eg: