| Impact | Details |
|---|---|
|
Modify Memory; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; DoS: Crash, Exit, or Restart; Bypass Protection Mechanism |
Scope: Integrity, Confidentiality, Availability, Access Control
Clearly, write-what-where conditions can be used to write data to areas of memory outside the scope of a policy. Also, they almost invariably can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.
|
|
DoS: Crash, Exit, or Restart; Modify Memory |
Scope: Integrity, Availability
Many memory accesses can lead to program termination, such as when writing to addresses that are invalid for the current process.
|
|
Bypass Protection Mechanism; Other |
Scope: Access Control, Other
When the consequence is arbitrary code execution, this can often be used to subvert any other security service.
|
| Phase(s) | Mitigation |
|---|---|
|
Architecture and Design |
Strategy: Language Selection Use a language that provides appropriate memory abstractions.
|
|
Operation |
Use OS-level preventative functionality integrated after the fact. Not a complete solution.
|
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Base 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. | 787 | Out-of-bounds Write |
| PeerOf | Variant 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 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') |
| CanFollow | Base 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. | 134 | Use of Externally-Controlled Format String |
| CanFollow | Base 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 | Variant 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. | 416 | Use After Free |
| CanFollow | Variant 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. | 479 | Signal Handler Use of a Non-reentrant Function |
| CanFollow | Variant 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. | 590 | Free of Memory not on the Heap |
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Base 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. | 787 | Out-of-bounds Write |
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Class 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. | 119 | Improper Restriction of Operations within the Bounds of a Memory Buffer |
| Phase | Note |
|---|---|
| Implementation |
C (Undetermined Prevalence)
C++ (Undetermined Prevalence)
Example 1
The classic example of a write-what-where condition occurs when the accounting information for memory allocations is overwritten in a particular fashion. Here is an example of potentially vulnerable code:
Vulnerability in this case is dependent on memory layout. The call to strcpy() can be used to write past the end of buf1, and, with a typical layout, can overwrite the accounting information that the system keeps for buf2 when it is allocated. Note that if the allocation header for buf2 can be overwritten, buf2 itself can be overwritten as well.
The allocation header will generally keep a linked list of memory "chunks". Particularly, there may be a "previous" chunk and a "next" chunk. Here, the previous chunk for buf2 will probably be buf1, and the next chunk may be null. When the free() occurs, most memory allocators will rewrite the linked list using data from buf2. Particularly, the "next" chunk for buf1 will be updated and the "previous" chunk for any subsequent chunk will be updated. The attacker can insert a memory address for the "next" chunk and a value to write into that memory address for the "previous" chunk.
This could be used to overwrite a function pointer that gets dereferenced later, replacing it with a memory address that the attacker has legitimate access to, where they have placed malicious code, resulting in arbitrary code execution.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
| Reference | Description |
|---|---|
| Ordinality | Description |
|---|---|
|
Resultant
|
(where the weakness is typically related to the presence of some other weaknesses)
|
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 970 | SFP Secondary Cluster: Faulty Buffer Access |
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 1160 | SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR) |
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 1161 | SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR) |
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 1399 | Comprehensive Categorization: Memory Safety |
Rationale
This CWE entry is at the Base 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.| Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
|---|---|---|---|
| CLASP | Write-what-where condition | ||
| CERT C Secure Coding | ARR30-C | Imprecise | Do not form or use out-of-bounds pointers or array subscripts |
| CERT C Secure Coding | ARR38-C | Imprecise | Guarantee that library functions do not form invalid pointers |
| CERT C Secure Coding | STR31-C | Imprecise | Guarantee that storage for strings has sufficient space for character data and the null terminator |
| CERT C Secure Coding | STR32-C | Imprecise | Do not pass a non-null-terminated character sequence to a library function that expects a string |
| Software Fault Patterns | SFP8 | Faulty Buffer Access |
| Submissions | ||
|---|---|---|
| Submission Date | Submitter | Organization |
|
2006年07月19日
(CWE Draft 3, 2006年07月19日) |
CLASP | |
| Modifications | ||
| Modification Date | Modifier | Organization |
|
2025年09月09日
(CWE 4.18, 2025年09月09日) |
CWE Content Team | MITRE |
| updated Affected_Resources, Functional_Areas, Observed_Examples | ||
|
2025年04月03日
(CWE 4.17, 2025年04月03日) |
CWE Content Team | MITRE |
| updated Relationships | ||
| 2023年10月26日 | CWE Content Team | MITRE |
| updated Observed_Examples | ||
| 2023年06月29日 | CWE Content Team | MITRE |
| updated Mapping_Notes | ||
| 2023年04月27日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2022年10月13日 | CWE Content Team | MITRE |
| updated Relationships, Taxonomy_Mappings | ||
| 2021年03月15日 | CWE Content Team | MITRE |
| updated References | ||
| 2020年12月10日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2020年08月20日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2020年02月24日 | CWE Content Team | MITRE |
| updated Relationships, Taxonomy_Mappings | ||
| 2019年09月19日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2019年06月20日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2019年01月03日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2017年11月08日 | CWE Content Team | MITRE |
| updated Causal_Nature, Common_Consequences, Demonstrative_Examples, Taxonomy_Mappings | ||
| 2015年12月07日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2014年07月30日 | CWE Content Team | MITRE |
| updated Relationships, Taxonomy_Mappings | ||
| 2013年02月21日 | CWE Content Team | MITRE |
| updated Potential_Mitigations | ||
| 2012年10月30日 | CWE Content Team | MITRE |
| updated Demonstrative_Examples | ||
| 2012年05月11日 | CWE Content Team | MITRE |
| updated Common_Consequences, References, Relationships | ||
| 2011年06月01日 | CWE Content Team | MITRE |
| updated Common_Consequences | ||
| 2010年12月13日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2009年05月27日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2009年01月12日 | CWE Content Team | MITRE |
| updated Common_Consequences | ||
| 2008年11月24日 | CWE Content Team | MITRE |
| updated Common_Consequences, Other_Notes | ||
| 2008年09月08日 | CWE Content Team | MITRE |
| updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities | ||
| 2008年07月01日 | Eric Dalci | Cigital |
| updated Time_of_Introduction | ||
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–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.