CWE-401: Improper Release of Memory Before Removing Last Reference ('Memory Leak')
Improper Release of 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.
Alternate Terms
Memory Leak
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
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() does not return the expected number of bytes:
(Bad Code)
Example
Language: 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.
To help correctly and consistently manage memory when programming in
C++, consider using a smart pointer class such as std::auto_ptr (defined
by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr
(specified by an upcoming revision of the C++ standard, informally
referred to as C++ 1x), or equivalent solutions such as Boost.
Phase: Architecture and Design
Use an abstraction library to abstract away risky APIs. Not a complete
solution.
Phases: Architecture and Design; Build and Compilation
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
CERT Java Secure Coding
MSC04-J
Do not leak memory
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.
Description
