| Attack Pattern ID | Pattern Abstraction: Detailed 47 |
| Typical Severity | High |
| Description | Summary
In this attack, the target software is given input that the attacker knows will be modified and expanded in size during processing. This attack relies on the target software failing to anticipate that the expanded data may exceed some internal limit, thereby creating a buffer overflow.
Attack Execution Flow
Consider parts of the program where user supplied data may be expanded by the program. Use a disassembler and other reverse engineering tools to guide the search.
Find a place where a buffer overflow occurs due to the fact that the new expanded size of the string is not correctly accounted for by the program. This may happen perhaps when the string is copied to another buffer that is big enough to hold the original, but not the expanded string. This may create an opportunity for planting the payload and redirecting program execution to the shellcode.
Write the buffer overflow exploit. To be exploitable, the "spill over" amount (e.g. the difference between the expanded string length and the original string length before it was expanded) needs to be sufficient to allow the overflow of the stack return pointer (in the case of a stack overflow), without causing a stack corruption that would crash the program before it gets to execute the shellcode. Heap overflow will be more difficult and will require the attacker to get more lucky, by perhaps getting a chance to overwrite some of the accounting information stored as part of using malloc().
|
| Attack Prerequisites |
The program expands one of the parameters passed to a function with input controlled by the user, but a later function making use of the expanded parameter erroneously considers the original, not the expanded size of the parameter.
The expanded parameter is used in the context where buffer overflow may becomes possible due to the incorrect understanding of the parameter size (i.e. thinking that it is smaller than it really is).
|
| Typical Likelihood of Exploit |
Medium
|
| Methods of Attack | |
| Examples-Instances | Description
Attack Example: FTP glob()
The glob() function in FTP servers has been susceptible to attack as a result of incorrect resizing. This is an ftpd glob() Expansion LIST Heap Overflow Vulnerability. ftp daemon contains a heap-based buffer overflow condition. The overflow occurs when the LIST command is issued with an argument that expands into an oversized string after being processed by glob().
This buffer overflow occurs in memory that is dynamically allocated. It may be possible for attackers to exploit this vulnerability and execute arbitrary code on the affected host.
To exploit this, the attacker must be able to create directories on the target host.
The glob() function is used to expand short-hand notation into complete file names. By sending to the FTP server a request containing a tilde (~) and other wildcard characters in the pathname string, a remote attacker can overflow a buffer and execute arbitrary code on the FTP server to gain root privileges. Once the request is processed, the glob() function expands the user input, which could exceed the expected length. In order to exploit this vulnerability, the attacker must be able to create directories on the FTP server.
From G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
Related Vulnerability Description
Buffer overflow in the glob implementation in libc in NetBSD-current before 20050914, and NetBSD 2.* and 3.* before 20061203, as used by the FTP daemon, allows remote authenticated users to execute arbitrary code via a long pathname that results from path expansion.
The limit computation of an internal buffer was done incorrectly. The
size of the buffer in byte was used as element count, even though the
elements of the buffer are 2 bytes long. Long expanded path names would
therefore overflow the buffer.
Related Vulnerability |
| Attacker Skill or Knowledge Required |
High: Finding this particular buffer overflow may not be trivial. Also, stack and especially heap based buffer overflows require a lot of knowledge if the intended goal is aribtrary code execution. Not only that the attacker needs to write the shell code to accomplish his or her goals, but the attacker also needs to find a way to get the program execution to jump to the planted shellcode. There also needs to be sufficient room for the payload. So not every buffer overflow will be exploitable, even by a skilled attacker.
|
| Resources Required |
Access to the program source or binary. If the program is only available in binary then a disassembler and other reverse engineering tools will be helpful.
|
| Solutions and Mitigations |
Ensure that when parameter expansion happens in the code that the assumptions used to determine the resulting size of the parameter are accurate and that the new size of the parameter is visible to the whole system
|
| Attack Motivation-Consequences | - Privilege Escalation
- Privilege Escalation
- Denial of Service
- Data Modification
|
| Context Description |
The Multiple Operation Problem
Whenever data are manipulated by a function, the function should track exactly what it’s doing to the data. This is straightforward when only one function is “munging” data. But when multiple operations are working on the same data, keeping track of the effects of each operation gets much harder. Incorrect tracking leads to big problems. This is especially true if the operation changes a string somehow.
There are a number of common operations on strings that will change the size of the string. The problem we’re discussing occurs if the code performing the conversion does not resize the buffer that the string lives in.
|
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 120 | Unbounded Transfer ('Classic Buffer Overflow') | Targeted | | 119 | Failure to Constrain Operations within the Bounds of an Allocated Memory Buffer | Targeted | | 118 | Range Errors | Targeted | | 130 | Length Parameter Inconsistency | Targeted | | 131 | Incorrect Calculation of Buffer Size | Targeted | | 74 | Failure to Sanitize Data into a Different Plane (aka 'Injection') | Targeted | | 20 | Insufficient Input Validation | Secondary |
|
| Related Attack Patterns | | ID | Name | Relationship Type | Relationship Description |
|---|
| 100 | Overflow Buffers | More Detailed | |
|
| Purpose | Penetration Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | High |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| All | All | All | All |
|
| References | G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. |
| 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 |
|---|
| Eugene Lebanidze | Cigital, Inc | 2007-02-26 | 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 Name, Description and Related Attack Patterns | | Sean Barnum | Cigital, Inc | 2007-04-13 | Modified pattern content according to review and feedback |
|
