Read Time:2 Minute, 24 Second

Description

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

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 they place 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.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-788
CWE-787

 

Consequences

Availability: Modify Memory, DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory)

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Integrity, Confidentiality, Availability, Access Control: Modify Memory, Execute Unauthorized Code or Commands, Bypass Protection Mechanism

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program’s implicit security policy.

Integrity, Confidentiality, Availability, Access Control, Other: Modify Memory, Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Other

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

 

Potential Mitigations

Phase: Build and Compilation

Effectiveness: Defense in Depth

Description: 

This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Architecture and Design

Description: 

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phase: Build and Compilation

Description: 

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.

Phase: Implementation

Description: 

Implement and perform bounds checking on input.

Phase: Implementation

Description: 

Do not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors.

Phase: Operation

Description: 

Use OS-level preventative functionality, such as ASLR. This is not a complete solution.

CVE References