|
| Home > CAPEC List > CAPEC-24: Filter Failure through Buffer Overflow (Release 1.4) |
|
 DescriptionSummary 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. lets the user input into the system unfiltered). Attack Execution Flow Explore
Experiment
Exploit
Attack PrerequisitesAbility to control the length of data passed to an active filter. Typical Likelihood of ExploitLikelihood: High Methods of Attack
Examples-InstancesDescription 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. Description 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. Description 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. Attacker Skills or Knowledge RequiredSkill or Knowledge 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. 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. Probing TechniquesTry to feed very long data as input to the program and watch for any indication that a failure has occurred. Then see if input has been admitted into the system. Some dynamic analysis tools may be helpful here to determine whether failure can be induced by feeding overly long inputs strings into the system. Indicators-Warnings of AttackMany 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. Obfuscation TechniquesAn attacker may temporally space out their probes. An attacker may perform probes from different IP addresses. Solutions and MitigationsMake 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. Attack Motivation-Consequences
Injection VectorWeb form, URL, File, Command line, Network socket, etc. PayloadAll of the data that just got into the system unfiltered becomes the payload. Activation ZoneSince the input enters the system effectively unfiltered, it may be dangerous if used in a SQL statement (i.e. SQL injection), as part of the command executed on the target system (i.e. command injection), as part of the reflection API (i.e. reflection injection), placed in logs (i.e. log injection), or perhaps to overflow another buffer in the system and give the attacker ability to execute arbitrary code. A subsequent buffer overflow may not even be required for that as the original one may be leveraged if the attacker gets lucky, that is the payload is activated in the filter itself, which also becomes the activation zone. Payload Activation ImpactSince no input validation is effectively performed in this situation, the impact of the attack may be a complete compromise of confidentiality, integrity, accountability and availability services. Related Weaknesses
Related Attack Patterns
Relevant Security RequirementsInput validation and filtering logic should fail securely (vault doors are closed) Related Security Principles
Related Guidelines
Purposes
CIA Impact
Technical Context
ReferencesG. Hoglund and G. McGraw.
"Exploiting Software: How to Break Code". Addison-Wesley. February 2004. CWE - Buffer Errors Content History
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Page Last Updated:
September 23, 2009
|
|
CAPEC is sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security. Vision and Technical Leadership provided by Cigital, Inc. This Web site is hosted by The MITRE Corporation. Contact capec@mitre.org for more information. |
|
|