Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Wiki MarkupDynamic memory management is a common source of programming flaws that can lead to security vulnerabilities. Decisions regarding how dynamic memory is allocated, used, and deallocated are the burden of the programmer. Poor memory management can lead to security issues, such as heap-buffer overflows, dangling pointers, and double-free issues \ [[Seacord 2005a|AA. Bibliography#Seacord 05]\]. From the programmer's perspective, memory management involves allocating memory, reading and writing to memory, and deallocating memory.

Allocating and freeing memory in different modules and levels of abstraction may make it difficult to determine when and if a block of memory has been freed, leading to programming defects, such as memory leaks, double-free vulnerabilities, accessing freed memory, or writing to freed or unallocated memory.unmigrated-wiki-markup

To avoid these situations, memory should be allocated and freed at the same level of abstraction and, ideally, in the same code module. This includes the use of the following memory allocation and deallocation functions described in C99, Section 7.20.3 \ [[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\]:

Code Block
void *malloc(size_t size);

void *calloc(size_t nmemb, size_t size);

void *realloc(void *ptr, size_t size);

void free(void *ptr);

Wiki MarkupFailing to follow this recommendation has led to real-world vulnerabilities. For example, freeing memory in different modules resulted in a vulnerability in MIT Kerberos 5 \ [[MIT 2004|AA. Bibliography#MIT 04]\]. The MIT Kerberos 5 code in this case contained error-handling logic, which freed memory allocated by the ASN.1 decoders if pointers to the allocated memory were non-null. However, if a detectable error occurred, the ASN.1 decoders freed the memory that they had allocated. When some library functions received errors from the ASN.1 decoders, they also attempted to free the same memory, resulting in a double-free vulnerability.

Noncompliant Code Example

...

Tool

Version

Checker

Description

Section

LDRA tool suite

Include Page
c:LDRA_Vc:
LDRA_V
Section

50 D

Section

Partially Implemented

Section

Fortify SCA

Section

V. 5.0

 

Section

can detect violations of this rule with CERT C Rule Pack

Section

Compass/ROSE

 

 

Section

could detect possible violations by reporting any function that has malloc() or free() but not both. This would catch some false positives, as there would be no way to tell if malloc() and free() are 'at the same level of abstraction' if they are in different functions

Section

Coverity Prevent

Include Page
c:Coverity_Vc:
Coverity_V
Section

USE_AFTER_FREE

Section

can detect the specific instances where Memory is deallocated more than once or Read/Write to target of a freed pointer

...

MITRE CWE: CWE-415, "Double Free"

Bibliography

Wiki Markup\[[MIT 2004|AA. Bibliography#MIT 04]\] \[]
[Plakosh 2005|AA. Bibliography#Plakosh 05]\] \[[Seacord 2005a|AA. Bibliography#Seacord 05]\] Chapter 4, "Dynamic Memory ]
[Seacord 2005a] Chapter 4, "Dynamic Memory Management"

...

08. Memory Management (MEM)      08. Memory Management (MEM)