| Attack Pattern ID | Pattern Abstraction: Detailed 14 |
| Typical Severity | High |
| Description | Summary This type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service. Attack Execution Flow 1. The attacker creates a custom hostile service 2. The attacker acquires information about the kind of client attaching to her hostile service to determine if it contains an exploitable buffer overflow vulnerability. 3. The attacker intentionally feeds malicious data to the client to exploit the buffer overflow vulnerability that she has uncovered. 4. The attacker leverages the exploit to execute arbitrary code or to cause a denial of service.
|
| Attack Prerequisites | The targeted client software communicates with an external server. The targeted client software has a buffer oveflow vulnerability. |
| Typical Likelihood of Exploit |
Medium
|
| Methods of Attack | |
| Examples-Instances | Description Attack Example: Buffer Overflow in Internet Explorer 4.0 Via EMBED Tag
Authors often use <EMBED> tags in HTML documents. For example
<EMBED TYPE="audio/midi" SRC="/path/file.mid" AUTOSTART="true">
If an attacker supplies an overly long path in the SRC= directive, the mshtml.dll component will suffer a buffer overflow. This is a standard example of content in a Web page being directed to exploit a faulty module in the system. There are potentially thousands of different ways data can propagate into a given system, thus these kinds of attacks will continue to be found in the wild. |
| Attacker Skill or Knowledge Required | Low : To achieve a denial of service, an attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector.
High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap requires a more in-depth knowledge and higher skill level.
|
| Probing Techniques | The server may look like a valid server, but in reality it may be a hostile server aimed at fooling the client software. For instance the server can use honey pots and get the client to download malicious code. Once engaged with the client, the hostile server may attempt to scan the client's host for open ports and potential vulnerabilities in the client software. The hostile server may also attempt to install and run malicious code on the client software. That malicious code can be used to scan the client software for buffer overflow. |
| Indicators-Warnings of Attack | An example of indicator is when the client software crashes after executing code downloaded from a hostile server. |
| Solutions and Mitigations | The client software should not install untrusted code from a non authenticated server. The client software should have the latest patches and should be audited for vulnerabilities before being used to communicate with potentially hostile servers. Perform input validation for length of buffer inputs. Use a language or compiler that performs automatic bounds checking. Use an abstraction library to abstract away risky APIs. Not a complete solution. 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. Ensure all buffer uses are consistently bounds-checked. Use OS-level preventative functionality. Not a complete solution. |
| Attack Motivation-Consequences | - Denial of Service
- Run Arbitrary Code
|
| Context Description | “Backwash Attacks: Leveraging Client-side Buffer Overflows
Nothing is more forward than directly attacking those who are attacking you. In many cases this philosophy is instantiated as a series of denial-of-service attacks launched in either direction. In standard scenarios, you can learn what IP address is being used to attack you, and then you can follow up with an attack of your own. (Be forewarned, however, that the legal ramifications of counterattack are drastic.) If the attacker is dumb enough to have open services, you may in some cases be able to own their system.
This has led some security types to consider a rather insidious tactic—creating hostile network services that look like valid targets. The basic idea builds on the idea of honey pots, but goes one important step further. Because most client software contains buffer overflows and other vulnerabilities, including a capacity to exploit these weaknesses directly when probed is within the realm of possibility.
Not surprisingly, of all the code that gets tested and probed in a security situation, client code is usually ignored. This is one of the reasons that client code ends up with more serious problems than server code. If a vulnerable client attaches to a hostile service, the hostile service can attempt to identify the type and version of the client that is connecting. This is a variety of fingerprinting.
Once the client is properly identified, the hostile server can issue a response that exploits a buffer overflow (or some other security defect) in the client. Typically this kind of attack is not designed simply just to crash the client. Attackers using this technique can inject a virus or backdoor into the original attacker’s computer using their own connection against them.
Obviously, this kind of “backwash attack” is a serious threat to an attacker. Anyone planning to attack arbitrary systems should assume that a backwash attack can and will happen. Any and all client software should be carefully audited before use.” |
| Payload | Attacker-supplied data potentially containing malicious code. |
| Activation Zone | When the function returns control to the main program, it jumps to the return address portion of the stack frame. Unfortunately that return address may have been overwritten by the overflowed buffer and the address may contain a call to a privileged command or to malicious code. |
| Payload Activation Impact | The most common are remote code execution or denial of service. |
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 120 | Unbounded Transfer ('Classic Buffer Overflow') | Targeted | | 353 | Failure to Add Integrity Check Value | Targeted | | 118 | Range Errors | Targeted | | 119 | Failure to Constrain Operations within the Bounds of an Allocated Memory Buffer | Targeted | | 74 | Failure to Sanitize Data into a Different Plane (aka 'Injection') | Targeted | | 20 | Insufficient Input Validation | Targeted |
|
| Related Attack Patterns | | ID | Name | Relationship Type | Relationship Description |
|---|
| 8 | Buffer Overflow in an API Call | More Detailed | |
|
| Related Security Principles | - Reluctance to Trust
- Defense in Depth
|
| Purpose | Penetration |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | High |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| Client-Server | All | All | All |
|
| References | G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE – Buffer Errors |
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. | Cigital, Inc | 2007-03-01 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Eric Dalci | Cigital, Inc | 2007-02-13 | Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" | | Sean Barnum | Cigital, Inc | 2007-03-05 | Review and revise | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Related Attack Patterns | | Sean Barnum | Cigital, Inc | 2007-04-13 | Modified pattern content according to review and feedback |
|
