Improper Release of Memory Before Removing Last Reference ('Memory Leak')ID: 401 | Date: (C)2012-05-14 (M)2022-10-10 |
Type: weakness | Status: DRAFT |
Abstraction Type: Base |
Description
The software does not sufficiently track and release allocated
memory after it has been used, which slowly consumes remaining
memory.
Extended DescriptionThis is often triggered by improper handling of malformed data or
unexpectedly interrupted sessions.
Likelihood of Exploit: Medium
Applicable PlatformsLanguage: CLanguage: C++
Time Of Introduction
- Architecture and Design
- Implementation
Common Consequences
Scope | Technical Impact | Notes |
---|
Availability | DoS: crash / exit /
restartDoS: instabilityDoS: resource consumption
(CPU)DoS: resource consumption
(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. |
Detection MethodsNone
Potential Mitigations
Phase | Strategy | Description | Effectiveness | Notes |
---|
Implementation | Libraries or Frameworks | 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. | | |
Architecture and Design | | Use an abstraction library to abstract away risky APIs. Not a complete
solution. | | |
Architecture and DesignBuild 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. |
RelationshipsThis is often a resultant weakness due to improper handling of malformed
data or early termination of sessions.
Related CWE | Type | View | Chain |
---|
CWE-401 ChildOf CWE-892 | Category | CWE-888 | |
Demonstrative Examples (Details)
- 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.
- The following C function leaks a block of allocated memory if the
call to read() does not return the expected number of bytes:
Observed Examples
- CVE-2005-3119 : Memory leak because function does not free() an element of a data structure.
- CVE-2004-0427 : Memory leak when counter variable is not decremented.
- CVE-2002-0574 : Memory leak when counter variable is not decremented.
- CVE-2005-3181 : Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code.
- CVE-2004-0222 : Memory leak via unknown manipulations as part of protocol test suite.
- CVE-2001-0136 : Memory leak via a series of the same command.
For more examples, refer to CVE relations in the bottom box.
White Box DefinitionsA weakness where the code path has:1. start statement that allocates dynamically allocated memory
resource2. end statement that loses identity of the dynamically allocated
memory resource creating situation where dynamically allocated memory
resource is never relinquishedWhere "loses" is defined through the following scenarios:1. identity of the dynamic allocated memory resource never
obtained2. 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 element3. identity of the dynamic allocated memory resource obtained but
never passed on to function for memory resource release4. 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
Black Box Definitions None
Taxynomy Mappings
Taxynomy | Id | Name | Fit |
---|
PLOVER | | Memory leak | |
7 Pernicious Kingdoms | | Memory Leak | |
CLASP | | Failure to deallocate data | |
OWASP Top Ten 2004 | A9 | Denial of Service | CWE_More_Specific |
CERT Java Secure Coding | MSC04-J | Do not leak memory | |
References:
- J. Whittaker H. Thompson .How to Break Software Security. Addison Wesley. Published on 2003.