|
|
|
|
CWE-415 Individual Dictionary Definition (Draft 9)
Weakness ID
| Status: Draft 415 (Weakness Variant) | | Description | Summary The product calls free() twice on
the same memory address, potentially leading to
modification of unexpected memory locations. | | Alternate Terms | Double-free | | Likelihood of Exploit | Low to Medium | | Affected Resource | Memory | | Common Consequences | Access control: Doubly freeing memory may result in a write-what-where
condition, allowing an attacker to execute arbitrary code. | | Potential Mitigations | Implementation: Ensure that each allocation is freed only once. After freeing a chunk,
set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error
conditions, be sure that clean-up routines respect the state of allocation properly. If the
language is object oriented, ensure that object destructors delete each chunk of memory only
once. | Demonstrative
Examples | Example 1: The following code shows a simple example of a double free vulnerability. char* ptr = (char*)malloc (SIZE);
...
if (abrt) { free(ptr); }
...
free(ptr); Double free vulnerabilities have two common (and sometimes overlapping) causes: -
Error conditions and other exceptional circumstances - Confusion over which part of the
program is responsible for freeing the memory Although some double free vulnerabilities
are not much more complicated than the previous example, most are spread out across
hundreds of lines of code or even different files. Programmers seem particularly
susceptible to freeing global variables more than once.
Example 2: While contrived, this code should be exploitable on Linux distributions
which do not ship with heap-chunk check summing turned on. #include <stdio.h>
#include <unistd.h>
#define BUFSIZE1 512
#define BUFSIZE2 ((BUFSIZE1/2) - 8)
int main(int argc, char **argv) {
char *buf1R1;
char *buf2R1;
char *buf1R2;
buf1R1 = (char *) malloc(BUFSIZE2);
buf2R1 = (char *) malloc(BUFSIZE2);
free(buf1R1);
free(buf2R1);
buf1R2 = (char *) malloc(BUFSIZE1);
strncpy(buf1R2, argv[1], BUFSIZE1-1);
free(buf2R1);
free(buf1R2);
} | | Observed Examples | | | Context Notes | This is usually resultant from another weakness, such as an unhandled error or race
condition between threads. It could also be primary to weaknesses such as buffer overflows. Also a Consequence. When a program calls free() twice with the same argument, the program's memory
management data structures become corrupted. This corruption can cause the program to crash or, in
some circumstances, cause two later calls to malloc() to return the same pointer. If malloc()
returns the same value twice and the program later gives the attacker control over the data that
is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow
attack.
It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but we're considering "Use" and "Release" to be distinct operations, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet.
| | Relationships | | | Source Taxonomies | PLOVER - DFREE - Double-Free Vulnerability 7 Pernicious Kingdoms - Double Free CLASP - Doubly freeing memory | | Applicable Platforms | C C++ |
|
- Weakness
- Base
- Variant
- Class
- Chain
- Composite
- Category
- View
- Deprecated
