Use After Free
Weakness ID: 416 (Weakness Base)Status: Draft
+ Description

Description Summary

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.
+ Alternate Terms
Use-After-Free
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Integrity

The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere.

Availability

If chunk consolidation occur after the use of previously freed data, the process may crash when invalid data is used as chunk information.

Integrity

If malicious data is entered before chunk consolidation can take place, it may be possible to take advantage of a write-what-where primitive to execute arbitrary code.

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

Example Language: C 
#include <stdio.h>
#include <unistd.h>
#define BUFSIZER1 512
#define BUFSIZER2 ((BUFSIZER1/2) - 8)
int main(int argc, char **argv) {
char *buf1R1;
char *buf2R1;
char *buf2R2;
char *buf3R2;
buf1R1 = (char *) malloc(BUFSIZER1);
buf2R1 = (char *) malloc(BUFSIZER1);
free(buf2R1);
buf2R2 = (char *) malloc(BUFSIZER2);
buf3R2 = (char *) malloc(BUFSIZER2);
strncpy(buf2R1, argv[1], BUFSIZER1-1);
free(buf1R1);
free(buf2R2);
free(buf3R2);
}

Example 2

The following code illustrates a use after free error:

(Bad Code)
Example Language: C 
char* ptr = (char*)malloc (SIZE); ...
if (err) {

abrt = 1;
free(ptr);
}
...
if (abrt) {
logError("operation aborted before commit", ptr);
}
+ Observed Examples
ReferenceDescription
CVE-2006-4997freed pointer dereference
+ Potential Mitigations

Phase: Architecture and Design

Choose a language that provides automatic memory management.

Phase: Implementation

Ensuring that all pointers are set to NULL once they memory they point to has been freed can be an effective strategy. The utilization of multiple or complex data structures may lower the usefulness of this strategy.

Phase: Implementation

Use a static analysis tool to find instances of use after free.

+ Other Notes

The use of previously freed memory can have any number of adverse consequences -- ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system's reuse of the freed memory. Like double free errors and memory leaks, use after free errors 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. In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data chances to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory399Resource Management Errors
Development Concepts (primary)699
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfWeakness BaseWeakness Base672Operation on a Resource after Expiration or Release
Research Concepts (primary)1000
ChildOfCategoryCategory742CERT C Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
CanPrecedeWeakness BaseWeakness Base120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base123Write-what-where Condition
Research Concepts1000
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
PeerOfWeakness BaseWeakness Base364Signal Handler Race Condition
Research Concepts1000
PeerOfWeakness VariantWeakness Variant415Double Free
Development Concepts699
Research Concepts1000
+ Affected Resources
  • Memory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsUse After Free
CLASPUsing freed memory
CERT C Secure CodingMEM00-CAllocate and free memory in the same module, at the same level of abstraction
CERT C Secure CodingMEM01-CStore a new value in pointers immediately after free()
CERT C Secure CodingMEM30-CDo not access freed memory
+ White Box Definitions

A weakness where code path has:

1. start statement that relinquishes a dynamically allocated memory resource

2. end statement that accesses the dynamically allocated memory resource

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential Mitigations, Time of Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Applicable Platforms, Common Consequences, Relationships, Observed Example, Other Notes, Taxonomy Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy Mappings
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative Examples
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative Examples
2009-10-29CWE Content TeamMITREInternal
updated Common Consequences
Back to top