| Name |
Buffer Overflow via Parameter Expansion |
|
| Likelyhood of attack |
Typical severity |
| Medium |
High |
|
| 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. |
| 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 become possible due to the incorrect understanding of the parameter size (i.e. thinking that it is smaller than it really is). |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
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. |
|
| 2 |
Experiment |
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 shell code. |
|
| 3 |
Exploit |
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 shell code. 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(). |
|
|
| Solutions | 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 |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-20 |
Improper Input Validation |
| CWE-74 |
Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') |
| CWE-118 |
Incorrect Access of Indexable Resource ('Range Error') |
| CWE-119 |
Improper Restriction of Operations within the Bounds of a Memory Buffer |
| CWE-120 |
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') |
| CWE-130 |
Improper Handling of Length Parameter Inconsistency |
| CWE-131 |
Incorrect Calculation of Buffer Size |
| CWE-680 |
Integer Overflow to Buffer Overflow |
| CWE-697 |
Incorrect Comparison |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-100 |
Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an adversary. As a consequence, an adversary is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the adversaries' choice. |
|