CWE-401: Failure to Release Memory Before Removing Last Reference ('Memory Leak')
Failure to Release Memory Before Removing Last Reference ('Memory Leak')
Weakness ID: 401 (Weakness Base)
Status: Draft
Description
Description Summary
The software does not sufficiently track and release allocated
memory after it has been used, which slowly consumes remaining
memory.
Extended Description
This is often triggered by improper handling of malformed data or
unexpectedly interrupted sessions.
Terminology Notes
"memory leak" has sometimes been used to describe other kinds of issues,
e.g. for information leaks in which the contents of memory are inadvertently
leaked (CVE-2003-0400 is one such example of this terminology
conflict).
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
C
C++
Modes of Introduction
Memory leaks 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
Common Consequences
Scope
Effect
Availability
Most memory leaks result in general software reliability problems, but
if an attacker can intentionally trigger a memory leak, the attacker
might be able to launch a denial of service attack (by crashing or
hanging the program) or take advantage of other unexpected program
behavior resulting from a low memory condition.
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
The following C function leaks a block of allocated memory if the
call to read() fails to return the expected number of bytes:
(Bad Code)
C
char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
}
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
return NULL;
}
return buf;
}
Example 2
Here the problem is that every time a connection is made, more
memory is allocated. So if one just opened up more and more connections,
eventually the machine would run out of memory.
Pre-design: Use a language or compiler that performs automatic bounds
checking.
Architecture and Design
Use an abstraction library to abstract away risky APIs. Not a complete
solution.
Pre-design through Build: The Boehm-Demers-Weiser Garbage Collector or
valgrind can be used to detect leaks in code. This is not a complete
solution as it is not 100% effective.
This is often a resultant weakness due to improper handling of malformed
data or early termination of sessions.
Affected Resources
Memory
Functional Areas
Memory management
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Memory leak
7 Pernicious Kingdoms
Memory Leak
CLASP
Failure to deallocate data
OWASP Top Ten 2004
A9
CWE More Specific
Denial of Service
White Box Definitions
A weakness where the code path has:
1. start statement that allocates dynamically allocated memory
resource
2. end statement that loses identity of the dynamically allocated
memory resource creating situation where dynamically allocated memory
resource is never relinquished
Where "loses" is defined through the following scenarios:
1. identity of the dynamic allocated memory resource never
obtained
2. the statement assigns another value to the data element that stored
the identity of the dynamically allocated memory resource and there are
no aliases of that data element
3. identity of the dynamic allocated memory resource obtained but
never passed on to function for memory resource release
4. the data element that stored the identity of the dynamically
allocated resource has reached the end of its scope at the statement and
there are no aliases of that data element
References
J. Whittaker and
H. Thompson. "How to Break Software Security". Addison Wesley. 2003.
Content History
Submissions
Submission Date
Submitter
Organization
Source
PLOVER
Externally Mined
Modifications
Modification Date
Modifier
Organization
Source
2008-07-01
Eric Dalci
Cigital
External
updated Time of Introduction
2008-08-01
KDM Analytics
External
added/updated white box definitions
2008-08-15
Veracode
External
Suggested OWASP Top Ten 2004
mapping
2008-09-08
CWE Content Team
MITRE
Internal
updated Applicable Platforms, Common Consequences,
Relationships, Other Notes, References, Relationship Notes,
Taxonomy Mappings, Terminology Notes
Description
