CAPEC-100 - Overflow Buffers

Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an attacker. As a consequence, an attacker is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the attackers' choice.

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 2
  • Injection
  • Analysis
  • Purposes 2
  • Penetration
  • Exploitation
  • Sec Principles 3
  • Reluctance To Trust
  • Defense in Depth
  • Failing Securely
  • Scopes 3
  • DoS: crash / exit / restart
  • Availability
  • Execute unauthorized code or commands
  • Availability
  • Integrity
  • Confidentiality
  • Gain privileges / assume identity
  • Authorization
  • Access_Control
  • Confidentiality

Low level: In most cases, overflowing a buffer does not require advanced skills beyond the ability to notice an overflow and stuff an input variable with content.

High level: In cases of directed overflows, where the motive is to divert the flow of the program or application as per the attackers' bidding, high level skills are required. This may involve detailed knowledge of the target system architecture and kernel.

Targeted software performs buffer operations.

Targeted software inadequately performs bounds-checking on buffer operations.

Attacker has the capability to influence the input to buffer operations.

None: Detecting and exploiting a buffer overflow does not require any resources beyond knowledge of and access to the target system.

The attacker sends an overly long input in variables under his control. If the target system or application handles it gracefully, the attack becomes difficult. However, an error condition or a system crash point to a high likelihood of successful exploitation.

In cases where the attack is directed at a particular system or application, such as an operating system or a web server, the attacker can refer to system architecture and design documentation to figure out the exact point of injection and exploitation.

Ensure that the Bounds of No Memory Region Are Violated

Never Use Unvalidated Input as Part of a Directive to any Internal Component

Step 1 -

The attacker identifies a buffer to target. Buffer regions are either allotted on the stack or the heap, and the exact nature of attack would vary depending on the location of the buffer.

Step 2 -

Next, the attacker identifies an injection vector to deliver the excessive content to the targeted buffer..


Step 1 -

The attacker crafts the content to be injected. If the intent is to simply cause the software to crash, the content need only consist of an excessive quantity of random data. If the intent is to leverage the overflow for execution of arbitrary code, the attacker will craft a set of content that not only overflows the targeted buffer but does so in such a way that the overwritten return address is replaced with one of the attackers' choosing which points to code injected by the attacker..


Step 1 -

The attacker injects the content into the targeted software..

Step 2 -

Upon successful exploitation, the system either crashes or control of the program is returned to a location of the attackers' choice. This can result in execution of arbitrary code or escalated privileges, depending upon the exploited target..


All user-controllable input must be strictly validated for enforcement of length and semantic checks

All exception conditions (such as ArrayIndexOutOfBounds) in applications must be gracefully handled through use of available exception handling mechanisms.

All applications and processes must be run with minimum privileges necessary so as to avoid an escalation of privilege in case of a successful exploit.

Use a language or compiler that performs automatic bounds checking.

Use secure functions not vulnerable to buffer overflow.

If you have to use dangerous functions, make sure that you do boundary checking.

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.

Use OS-level preventative functionality. Not a complete solution.

Utilize static source code analysis tools to identify potential buffer overflow weaknesses in the software.