Home > CAPEC List > CAPEC-24: Filter Failure through Buffer Overflow (Version 3.9)

CAPEC-24: Filter Failure through Buffer Overflow

Attack Pattern ID: 24
Abstraction: Detailed
View customized information:
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).
Likelihood Of Attack

High

Typical Severity

High

Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.100Overflow Buffers
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
Execution Flow
Explore

  1. Survey: The attacker surveys the target application, possibly as a valid and authenticated user

    Techniques
    Spidering web sites for inputs that involve potential filtering
    Brute force guessing of filtered inputs
Experiment

  1. Attempt injections: Try to feed overly long data to the system. This can be done manually or a dynamic tool (black box) can be used to automate this. An attacker can also use a custom script for that purpose.

    Techniques
    Brute force attack through black box penetration test tool.
    Fuzzing of communications protocols
    Manual testing of possible inputs with attack data.

  2. Monitor responses: Watch for any indication of failure occurring. Carefully watch to see what happened when filter failure occurred. Did the data get in?

    Techniques
    Boron tagging. Choose clear attack inputs that are easy to notice in output. In binary this is often 0xa5a5a5a5 (alternating 1s and 0s). Another obvious tag value is all zeroes, but it is not always obvious what goes wrong if the null values get into the data.
    Check Log files. An attacker with access to log files can look at the outcome of bad input.
Exploit

  1. Abuse the system through filter failure: An attacker writes a script to consistently induce the filter failure.

    Techniques
    DoS through filter failure. The attacker causes the system to crash or stay down because of its failure to filter properly.
    Malicious code execution. An attacker introduces a malicious payload and executes arbitrary code on the target system.
    An attacker can use the filter failure to introduce malicious data into the system and leverage a subsequent SQL injection, Cross Site Scripting, Command Injection or similar weakness if it exists.
Prerequisites
Ability to control the length of data passed to an active filter.
Skills Required
[Level: 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.
[Level: 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.
Indicators
Many exceptions are thrown by the application's filter modules in a short period of time. Check the logs. See if the probes are coming from the same IP address.
Consequences
Section HelpThis table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
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.
Example Instances

Sending in arguments that are too long to cause the filter to fail open is one instantiation of the filter failure attack. The Taylor UUCP daemon is designed to remove hostile arguments before they can be executed. If the arguments are too long, however, the daemon fails to remove them. This leaves the door open for attack.

A filter is used by a web application to filter out characters that may allow the input to jump from the data plane to the control plane when data is used in a SQL statement (chaining this attack with the SQL injection attack). Leveraging a buffer overflow the attacker makes the filter fail insecurely and the tainted data is permitted to enter unfiltered into the system, subsequently causing a SQL injection.
Audit Truncation and Filters with Buffer Overflow. Sometimes very large transactions can be used to destroy a log file or cause partial logging failures. In this kind of attack, log processing code might be examining a transaction in real-time processing, but the oversized transaction causes a logic branch or an exception of some kind that is trapped. In other words, the transaction is still executed, but the logging or filtering mechanism still fails. This has two consequences, the first being that you can run transactions that are not logged in any way (or perhaps the log entry is completely corrupted). The second consequence is that you might slip through an active filter that otherwise would stop your attack.
References
[REF-1] G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. 2004-02.
Content History
Submissions
Submission DateSubmitterOrganization
2014年06月23日
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2017年01月09日
(Version 2.9)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns
2018年07月31日
(Version 2.12)
CAPEC Content TeamThe MITRE Corporation
Updated References
2022年09月29日
(Version 3.8)
CAPEC Content TeamThe MITRE Corporation
Updated Example_Instances
More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018

Use of the Common Attack Pattern Enumeration and Classification (CAPEC), and the associated references from this website are subject to the Terms of Use. Copyright © 2007–2025, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.

AltStyle によって変換されたページ (->オリジナル) /