CWE

Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.8)  

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

Languages

C

C++

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability
Access Control

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.

Integrity
Availability

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.

Access Control
Other

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

High

+ 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]);
free(buf2);
}

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
OrdinalityDescription
Resultant
(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
ChildOfCategoryCategory970SFP Secondary Cluster: Faulty Buffer 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

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPWrite-what-where condition
Software Fault PatternsSFP8Faulty Buffer Access
+ 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
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITREInternal
updated Common_Consequences, Other_Notes
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences
2009-05-27CWE Content TeamMITREInternal
updated Relationships
2010-12-13CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Page Last Updated: July 30, 2014