Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.7)  

Presentation Filter:

CWE-123: Write-what-where Condition

Write-what-where Condition
Weakness ID: 123 (Weakness Base)Status: Draft
+ Description

Description Summary

Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
+ Time of Introduction
  • Implementation
+ Applicable Platforms




+ Common Consequences

Technical Impact: Modify memory; Execute unauthorized code or commands; Gain privileges / assume identity; DoS: crash / exit / restart; Bypass protection mechanism

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), he can redirect a function pointer to his 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.

Technical Impact: DoS: crash / exit / restart; Modify memory

Many memory accesses can lead to program termination, such as when writing to addresses that are invalid for the current process.

Technical Impact: Bypass protection mechanism; Other

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

+ Likelihood of Exploit


+ Demonstrative Examples

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:

(Bad Code)
Example Language:
#define BUFSIZE 256
int main(int argc, char **argv) {
char *buf1 = (char *) malloc(BUFSIZE);
char *buf2 = (char *) malloc(BUFSIZE);
strcpy(buf1, argv[1]);

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 he has placed malicious code, resulting in arbitrary code execution.

+ Potential Mitigations

Phase: Architecture and Design

Strategy: Language Selection

Use a language that provides appropriate memory abstractions.

Phase: Operation

Use OS-level preventative functionality integrated after the fact. Not a complete solution.

+ Weakness Ordinalities
(where the weakness is typically related to the presence of some other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class119Improper Restriction of Operations within the Bounds of a Memory Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory890SFP Cluster: Memory Access
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base134Uncontrolled Format String
Research Concepts1000
CanFollowWeakness BaseWeakness Base120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Research Concepts1000
CanFollowWeakness BaseWeakness Base364Signal Handler Race Condition
Research Concepts1000
CanFollowWeakness BaseWeakness Base416Use After Free
Research Concepts1000
CanFollowWeakness VariantWeakness Variant479Signal Handler Use of a Non-reentrant Function
Research Concepts1000
CanFollowWeakness VariantWeakness Variant590Free of Memory not on the Heap
Research Concepts1000
PeerOfWeakness VariantWeakness Variant415Double Free
Research Concepts1000
+ Causal Nature


+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPWrite-what-where condition
+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
+ Content History
Submission DateSubmitterOrganizationSource
Externally Mined
Modification DateModifierOrganizationSource
updated Time_of_Introduction
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
updated Common_Consequences, Other_Notes
updated Common_Consequences
updated Relationships
updated Relationships
updated Common_Consequences
updated Common_Consequences, References, Relationships
updated Demonstrative_Examples
updated Potential_Mitigations
Page Last Updated: June 23, 2014