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

Weakness ID: 416

Abstraction: Variant
Structure: Simple

Status: Stable

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

This table 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 still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	825	Expired Pointer Dereference
PeerOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	415	Double Free
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	364	Signal Handler Race Condition
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1265	Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	120	Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	123	Write-what-where Condition

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	672	Operation on a Resource after Expiration or Release

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	672	Operation on a Resource after Expiration or Release

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	672	Operation on a Resource after Expiration or Release

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

This listing shows 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

This table 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.	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.	971	SFP Secondary Cluster: Faulty Pointer 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)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1200	Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1337	Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1350	Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses

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	SFP7		Faulty Pointer Use

References

[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.

[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.

[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
2006-07-19	7 Pernicious Kingdoms
2006-07-19
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
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships, Type
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships, Taxonomy_Mappings
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Relationships


	Site Map \| Terms of Use \| Privacy Policy \| Contact Us \| Use of the Common Weakness Enumeration (CWE) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006-2021, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

Common Weakness Enumeration

CWE-416: Use After Free