CWE

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.6)  

Presentation Filter:

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

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: crash / exit / restart; DoS: instability; DoS: 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.

+ 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:
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.

(Bad Code)
Example Language:
bar connection(){
foo = malloc(1024);
return foo;
}
endConnection(bar foo) {

free(foo);
}
int main() {

while(1) //thread 1
//On a connection
foo=connection(); //thread 2
//When the connection ends
endConnection(foo)
}
+ Observed Examples
ReferenceDescription
CVE-2005-3119Memory leak because function does not free() an element of a data structure.
CVE-2004-0427Memory leak when counter variable is not decremented.
CVE-2002-0574chain: reference count is not decremented, leading to memory leak in OS by sending ICMP packets.
CVE-2005-3181Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code.
CVE-2004-0222Memory leak via unknown manipulations as part of protocol test suite.
CVE-2001-0136Memory leak via a series of the same command.
+ Potential Mitigations

Phase: Implementation

Strategy: Libraries or Frameworks

Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.

For example, glibc in Linux provides protection against free of invalid pointers.

When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [R.401.2].

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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory399Resource Management Errors
Development Concepts (primary)699
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness BaseWeakness Base772Missing Release of Resource after Effective Lifetime
Research Concepts (primary)1000
ChildOfCategoryCategory861CERT Java Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory892SFP Cluster: Resource Management
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
CanFollowWeakness ClassWeakness Class390Detection of Error Condition Without Action
Research Concepts1000
+ Relationship Notes

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 NameNode IDFitMapped Node Name
PLOVERMemory leak
7 Pernicious KingdomsMemory Leak
CLASPFailure to deallocate data
OWASP Top Ten 2004A9CWE_More_SpecificDenial of Service
CERT Java Secure CodingMSC04-JDo 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
[R.401.1] J. Whittaker and H. Thompson. "How to Break Software Security". Addison Wesley. 2003.
[R.401.2] [REF-36] iOS Developer Library. "Transitioning to ARC Release Notes". 2013-08-08. <https://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, References, Relationship_Notes, Taxonomy_Mappings, Terminology_Notes
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-03-10CWE Content TeamMITREInternal
updated Other_Notes
2009-05-27CWE Content TeamMITREInternal
updated Name
2009-07-17KDM AnalyticsExternal
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITREInternal
updated White_Box_Definitions
2009-10-29CWE Content TeamMITREInternal
updated Modes_of_Introduction, Other_Notes
2010-02-16CWE Content TeamMITREInternal
updated Relationships
2010-06-21CWE Content TeamMITREInternal
updated Other_Notes, Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Demonstrative_Examples, Name
2011-03-29CWE Content TeamMITREInternal
updated Alternate_Terms
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Observed_Examples
2014-02-18CWE Content TeamMITREInternal
updated Potential_Mitigations, References
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Memory Leak
2009-05-27Failure to Release Memory Before Removing Last Reference (aka 'Memory Leak')
2010-12-13Failure to Release Memory Before Removing Last Reference ('Memory Leak')
Page Last Updated: February 18, 2014