CWE - CWE-416: Use After Free (3.2)

Weakness ID: 416

Abstraction: Base
Structure: Simple

Status: Draft

Presentation Filter:

Description

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Extended Description

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. 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.

Alternate Terms

Dangling pointer
Use-After-Free

Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Base - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.	825	Expired Pointer Dereference
PeerOf	Variant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.	415	Double Free
CanFollow	Base - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.	364	Signal Handler Race Condition
CanPrecede	Base - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.	120	Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CanPrecede	Base - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.	123	Write-what-where Condition

Relevant to the view "Development Concepts" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	399	Resource Management Errors
PeerOf	Variant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.	415	Double Free

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Architecture and Design
Implementation

Applicable Platforms

The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
Integrity	Technical Impact: Modify Memory The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere.
Availability	Technical Impact: DoS: Crash, Exit, or Restart If chunk consolidation occurs after the use of previously freed data, the process may crash when invalid data is used as chunk information.
Integrity Confidentiality Availability	Technical Impact: Execute Unauthorized Code or Commands 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

The following example demonstrates the weakness.

(bad code)

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);

}

When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.

Observed Examples

Reference	Description
CVE-2010-4168	Use-after-free triggered by closing a connection while data is still being transmitted.
CVE-2010-2941	Improper allocation for invalid data leads to use-after-free.
CVE-2010-2547	certificate with a large number of Subject Alternate Names not properly handled in realloc, leading to use-after-free
CVE-2010-1772	Timers are not disabled when a related object is deleted
CVE-2010-1437	Access to a "dead" object that is being cleaned up
CVE-2010-1208	object is deleted even with a non-zero reference count, and later accessed
CVE-2010-0629	use-after-free involving request containing an invalid version number
CVE-2010-0378	unload of an object that is currently being accessed by other functionality
CVE-2010-0302	incorrectly tracking a reference count leads to use-after-free
CVE-2010-0249	use-after-free related to use of uninitialized memory
CVE-2010-0050	HTML document with incorrectly-nested tags
CVE-2009-3658	Use after free in ActiveX object by providing a malformed argument to a method
CVE-2009-3616	use-after-free by disconnecting during data transfer, or a message containing incorrect data types
CVE-2009-3553	disconnect during a large data transfer causes incorrect reference count, leading to use-after-free
CVE-2009-2416	use-after-free found by fuzzing
CVE-2009-1837	Chain: race condition (CWE-362) from improper handling of a page transition in web client while an applet is loading (CWE-368) leads to use after free (CWE-416)
CVE-2009-0749	realloc generates new buffer and pointer, but previous pointer is still retained, leading to use after free
CVE-2010-3328	Use-after-free in web browser, probably resultant from not initializing memory.
CVE-2008-5038	use-after-free when one thread accessed memory that was freed by another thread
CVE-2008-0077	assignment of malformed values to certain properties triggers use after free
CVE-2006-4434	mail server does not properly handle a long header.
CVE-2010-2753	chain: integer overflow leads to use-after-free
CVE-2006-4997	freed pointer dereference

Potential Mitigations

Phase: Architecture and Design

Choose a language that provides automatic memory management.

Phase: Implementation

When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.

Affected Resources

Memory

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	398	7PK - Code Quality
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	399	Resource Management Errors
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	808	2010 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	876	CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	983	SFP Secondary Cluster: Faulty Resource Use
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1162	SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Use After Free
CLASP			Using freed 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	MEM30-C	Exact	Do not access freed memory
Software Fault Patterns	SFP15		Faulty Resource Use

References

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.

Content History

Submissions
Submission Date	Submitter	Organization
	7 Pernicious Kingdoms

Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Demonstrative_Examples
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Relationships
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Potential_Mitigations
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Observed_Examples, Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Alternate_Terms, Common_Consequences, Description, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Description
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Demonstrative_Examples
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships


	Use of the Common Weakness Enumeration and the associated references from this website are subject to the Terms of Use. For more information, please email cwe@mitre.org. CWE is sponsored by US-CERT in the office of Cybersecurity and Communications at the U.S. Department of Homeland Security. Copyright © 2006-2019, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.	Privacy Policy Terms of Use Site Map Contact Us

Common Weakness Enumeration

CWE-416: Use After Free