Weakness ID: 416 Vulnerability Mapping:
ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities Abstraction: VariantVariant - 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. |
Description The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. | |
Alternate Terms
Dangling pointer: | a pointer that no longer points to valid memory, often after it has been freed |
UAF: | commonly used acronym for Use After Free |
Use-After-Free | |
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. If the newly allocated data happens 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. | |
Potential Mitigations
Phase: Architecture and Design Strategy: Language Selection Choose a language that provides automatic memory management. |
Phase: Implementation Strategy: Attack Surface Reduction 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. Effectiveness: Defense in Depth Note: If a bug causes an attempted access of this pointer, then a NULL dereference could still lead to a crash or other unexpected behavior, but it will reduce or eliminate the risk of code execution. |
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 | 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. | 362 | Concurrent Execution using Shared Resource with Improper Synchronization ('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. | 364 | Signal Handler Race Condition | CanFollow | 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. | 754 | Improper Check for Unusual or Exceptional Conditions | 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 |
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 "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 |
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 "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 |
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 "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. Likelihood Of Exploit 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 |
| Chain: an operating system kernel has insufficent resource locking ( CWE-413) leading to a use after free ( CWE-416). |
| Chain: two threads in a web browser use the same resource ( CWE-366), but one of those threads can destroy the resource before the other has completed ( CWE-416). |
| Chain: mobile platform race condition ( CWE-362) leading to use-after-free ( CWE-416), as exploited in the wild per CISA KEV. |
| Chain: race condition ( CWE-362) leads to use-after-free ( CWE-416), as exploited in the wild per CISA KEV. |
| Use-after-free triggered by closing a connection while data is still being transmitted. |
| Improper allocation for invalid data leads to use-after-free. |
| certificate with a large number of Subject Alternate Names not properly handled in realloc, leading to use-after-free |
| Timers are not disabled when a related object is deleted |
| Access to a "dead" object that is being cleaned up |
| object is deleted even with a non-zero reference count, and later accessed |
| use-after-free involving request containing an invalid version number |
| unload of an object that is currently being accessed by other functionality |
| incorrectly tracking a reference count leads to use-after-free |
| use-after-free related to use of uninitialized memory |
| HTML document with incorrectly-nested tags |
| Use after free in ActiveX object by providing a malformed argument to a method |
| use-after-free by disconnecting during data transfer, or a message containing incorrect data types |
| disconnect during a large data transfer causes incorrect reference count, leading to use-after-free |
| use-after-free found by fuzzing |
| 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) |
| realloc generates new buffer and pointer, but previous pointer is still retained, leading to use after free |
| Use-after-free in web browser, probably resultant from not initializing memory. |
| use-after-free when one thread accessed memory that was freed by another thread |
| assignment of malformed values to certain properties triggers use after free |
| mail server does not properly handle a long header. |
| chain: integer overflow leads to use-after-free |
| freed pointer dereference |
Weakness Ordinalities Ordinality | Description |
Resultant | (where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect) If the product accesses a previously-freed pointer, then it means that a separate weakness or error already occurred previously, such as a race condition, an unexpected or poorly handled error condition, confusion over which part of the program is responsible for freeing the memory, performing the free too soon, etc. |
Detection Methods
Fuzzing Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues. |
Automated Static Analysis Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) |
Affected Resources 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. Vulnerability Mapping Notes Usage: ALLOWED (this CWE ID could be used to map to real-world vulnerabilities) | Reason: Acceptable-Use | Rationale: This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities. | Comments: Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction. |
Taxonomy Mappings Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
ISA/IEC 62443 | Part 4-1 | | Req SI-1 |
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 |
---|
2006-07-19 (CWE Draft 3, 2006-07-19) | 7 Pernicious Kingdoms | | | Contributions |
---|
Contribution Date | Contributor | Organization |
---|
2022-06-28 | Anonymous External Contributor | | Suggested rephrase for extended description | 2023-11-14 (CWE 4.14, 2024-02-29) | participants in the CWE ICS/OT SIG 62443 Mapping Fall Workshop | | Contributed or reviewed taxonomy mappings for ISA/IEC 62443 | 2024-02-29 (CWE 4.15, 2024-07-16) | Abhi Balakrishnan | | Provided diagram to improve CWE usability | Modifications |
---|
Modification Date | Modifier | Organization |
---|
2008-07-01 | Eric Dalci | Cigital | updated Potential_Mitigations, Time_of_Introduction | 2008-08-01 | | KDM Analytics | added/updated white box definitions | 2008-09-08 | CWE Content Team | MITRE | updated Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings | 2008-11-24 | CWE Content Team | MITRE | updated Relationships, Taxonomy_Mappings | 2009-03-10 | CWE Content Team | MITRE | updated Demonstrative_Examples | 2009-05-27 | CWE Content Team | MITRE | updated Demonstrative_Examples | 2009-10-29 | CWE Content Team | MITRE | updated Common_Consequences | 2010-02-16 | CWE Content Team | MITRE | updated Relationships | 2010-06-21 | CWE Content Team | MITRE | updated Potential_Mitigations | 2010-09-27 | CWE Content Team | MITRE | updated Observed_Examples, Relationships | 2010-12-13 | CWE Content Team | MITRE | updated Alternate_Terms, Common_Consequences, Description, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships | 2011-03-29 | CWE Content Team | MITRE | updated Description | 2011-06-01 | CWE Content Team | MITRE | updated Common_Consequences | 2011-06-27 | CWE Content Team | MITRE | updated Demonstrative_Examples | 2011-09-13 | CWE Content Team | MITRE | updated Relationships, Taxonomy_Mappings | 2012-05-11 | CWE Content Team | MITRE | updated References, Relationships | 2014-07-30 | CWE Content Team | MITRE | updated Relationships, Taxonomy_Mappings | 2015-12-07 | CWE Content Team | MITRE | updated Relationships | 2017-11-08 | CWE Content Team | MITRE | updated Demonstrative_Examples, Relationships, Taxonomy_Mappings, White_Box_Definitions | 2019-01-03 | CWE Content Team | MITRE | updated Relationships | 2019-06-20 | CWE Content Team | MITRE | updated Relationships, Type | 2019-09-19 | CWE Content Team | MITRE | updated Relationships | 2020-02-24 | CWE Content Team | MITRE | updated References, Relationships, Taxonomy_Mappings | 2020-06-25 | CWE Content Team | MITRE | updated Relationships | 2020-08-20 | CWE Content Team | MITRE | updated Relationships | 2020-12-10 | CWE Content Team | MITRE | updated Relationships | 2021-07-20 | CWE Content Team | MITRE | updated Relationships | 2022-06-28 | CWE Content Team | MITRE | updated Observed_Examples, Relationships | 2022-10-13 | CWE Content Team | MITRE | updated Description, Relationships, Taxonomy_Mappings | 2023-04-27 | CWE Content Team | MITRE | updated Detection_Factors, Relationships, Time_of_Introduction | 2023-06-29 | CWE Content Team | MITRE | updated Mapping_Notes, Relationships | 2023-10-26 | CWE Content Team | MITRE | updated Observed_Examples | 2024-02-29 (CWE 4.14, 2024-02-29) | CWE Content Team | MITRE | updated Taxonomy_Mappings | 2024-07-16 (CWE 4.15, 2024-07-16) | CWE Content Team | MITRE | updated Alternate_Terms, Common_Consequences, Description, Diagram, Potential_Mitigations, Relationships, Weakness_Ordinalities |
More information is available — Please edit the custom filter or select a different filter.
|