Double Free |
Weakness ID: 415 (Weakness Variant) | Status: Draft |
Description Summary
Extended Description
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.
Scope | Effect |
---|---|
Access Control | Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code. |
Example 1
The following code shows a simple example of a double free vulnerability.
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.
Reference | Description |
---|---|
CVE-2004-0642 | Double free resultant from certain error conditions. |
CVE-2004-0772 | Double free resultant from certain error conditions. |
CVE-2005-1689 | Double free resultant from certain error conditions. |
CVE-2003-0545 | Double free from invalid ASN.1 encoding. |
CVE-2003-1048 | Double free from malformed GIF. |
CVE-2005-0891 | Double free from malformed GIF. |
CVE-2002-0059 | Double free from malformed compressed data. |
Phase: Architecture and Design Choose a language that provides automatic memory management. |
Phase: 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. |
Phase: Implementation Use a static analysis tool to find double free instances. |
Nature | Type | ID | Name | View(s) this relationship pertains to |
---|---|---|---|---|
ChildOf | Weakness Class | 398 | Indicator of Poor Code Quality | Seven Pernicious Kingdoms (primary)700 |
ChildOf | Category | 399 | Resource Management Errors | Development Concepts (primary)699 |
ChildOf | Category | 633 | Weaknesses that Affect Memory | Resource-specific Weaknesses (primary)631 |
ChildOf | Weakness Base | 666 | Operation on Resource in Wrong Phase of Lifetime | Research Concepts (primary)1000 |
ChildOf | Weakness Class | 675 | Duplicate Operations on Resource | Research Concepts1000 |
ChildOf | Category | 742 | CERT C Secure Coding Section 08 - Memory Management (MEM) | Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734 |
PeerOf | Weakness Base | 123 | Write-what-where Condition | Research Concepts1000 |
PeerOf | Weakness Base | 416 | Use After Free | Development Concepts699 Research Concepts1000 |
MemberOf | View | 630 | Weaknesses Examined by SAMATE | Weaknesses Examined by SAMATE (primary)630 |
PeerOf | Weakness Base | 364 | Signal Handler Race Condition | Research Concepts1000 |
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. |
Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
---|---|---|---|
PLOVER | DFREE - Double-Free Vulnerability | ||
7 Pernicious Kingdoms | Double Free | ||
CLASP | Doubly freeing memory | ||
CERT C Secure Coding | MEM00-C | Allocate and free memory in the same module, at the same level of abstraction | |
CERT C Secure Coding | MEM01-C | Store a new value in pointers immediately after free() | |
CERT C Secure Coding | MEM31-C | Free dynamically allocated memory exactly once |
A weakness where code path has: 1. start statement that relinquishes a dynamically allocated memory resource 2. end statement that relinquishes the dynamically allocated memory resource |
It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but "Use" and "Release" are considered to be distinct operations within vulnerability theory, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet. |
Submissions | ||||
---|---|---|---|---|
Submission Date | Submitter | Organization | Source | |
PLOVER | Externally Mined | |||
Modifications | ||||
Modification Date | Modifier | Organization | Source | |
2008-07-01 | Eric Dalci | Cigital | External | |
updated Potential Mitigations, Time of Introduction | ||||
2008-08-01 | KDM Analytics | External | ||
added/updated white box definitions | ||||
2008-09-08 | CWE Content Team | MITRE | Internal | |
updated Applicable Platforms, Common Consequences, Description, Maintenance Notes, Relationships, Other Notes, Relationship Notes, Taxonomy Mappings | ||||
2008-11-24 | CWE Content Team | MITRE | Internal | |
updated Relationships, Taxonomy Mappings | ||||
2009-05-27 | CWE Content Team | MITRE | Internal | |
updated Demonstrative Examples | ||||
2009-10-29 | CWE Content Team | MITRE | Internal | |
updated Other Notes |