Umbra Wiki attack-pattern attack-pattern/CAPEC-24
Back to wiki

CAPEC-24 — Filter Failure through Buffer Overflow

provenance: imported · CWE: CWE-20 CWE-74 CWE-118 CWE-119 CWE-120 CWE-680 CWE-697 CWE-733

CAPEC-24: Filter Failure through Buffer Overflow

MITRE CAPEC attack pattern

Status Draft
Typical severity High
Likelihood of attack High
Catalogue CAPEC 3.9 (2023-01-24)

Description

In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. the user input is let into the system unfiltered).

Where this sits in the chain

A finding maps to a weakness (CWE), a weakness is exploited by an attack pattern (CAPEC), and an attack pattern shows up in ATT&CK as observed adversary behaviour. This page is the middle hop.

Weaknesses exploited: CWE-20, CWE-74, CWE-118, CWE-119, CWE-120, CWE-680, CWE-697, CWE-733

Prerequisites

  • Ability to control the length of data passed to an active filter.

Skills required

  • Low: An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector. The result can be a DoS.
  • High: Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.

Consequences

  • Integrity: Modify Data
  • Confidentiality, Integrity, Availability: Execute Unauthorized Commands
  • Confidentiality, Access Control, Authorization: Bypass Protection Mechanism
  • Availability: Unreliable Execution

Mitigations

  • Make sure that ANY failure occurring in the filtering or input validation routine is properly handled and that offending input is NOT allowed to go through. Basically make sure that the vault is closed when failure occurs.
  • Pre-design: Use a language or compiler that performs automatic bounds checking.
  • 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.
  • Design: Use an abstraction library to abstract away risky APIs. Not a complete solution.

Source