[Forgot Password]
Login  Register Subscribe

30389

 
 

423868

 
 

244411

 
 

909

 
 

193363

 
 

277

Paid content will be excluded from the download.


Download | Alert*
CWE
view XML

Improper Release of Memory Before Removing Last Reference ('Memory Leak')

ID: 401Date: (C)2012-05-14   (M)2022-10-10
Type: weaknessStatus: 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 Description

This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions.

Likelihood of Exploit: Medium

Applicable Platforms
Language: C
Language: C++

Time Of Introduction

  • Architecture and Design
  • Implementation

Common Consequences

ScopeTechnical ImpactNotes
Availability
 
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.
 

Detection Methods
None

Potential Mitigations

PhaseStrategyDescriptionEffectivenessNotes
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 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
This is often a resultant weakness due to improper handling of malformed data or early termination of sessions.

Related CWETypeViewChain
CWE-401 ChildOf CWE-892 Category CWE-888  

Demonstrative Examples   (Details)

  1. 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.
  2. 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

  1. CVE-2005-3119 : Memory leak because function does not free() an element of a data structure.
  2. CVE-2004-0427 : Memory leak when counter variable is not decremented.
  3. CVE-2002-0574 : Memory leak when counter variable is not decremented.
  4. CVE-2005-3181 : Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code.
  5. CVE-2004-0222 : Memory leak via unknown manipulations as part of protocol test suite.
  6. 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 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

Black Box Definitions
None

Taxynomy Mappings

TaxynomyIdNameFit
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:

  1. J. Whittaker H. Thompson .How to Break Software Security. Addison Wesley. Published on 2003.
CVE    276
CVE-2007-2274
CVE-2016-10155
CVE-2016-9916
CVE-2016-9915
...

© SecPod Technologies