Page History

Dynamic memory management is a common source of programming flaws that can lead to security vulnerabilities. Poor memory management can lead to security issues, such as heap-buffer overflows, dangling pointers, and double-free issues [Seacord 2013]. 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 burdens the programmer with tracking the lifetime of that block of memory. This may cause confusion regarding may make it difficult to determine when and if a block of memory has been allocated or freed, leading to programming defects, such as memory leaks, double-free vulnerabilities, accessing freed memory, or writing to freed or unallocated memory.

To avoid these situations, it is recommended that memory should be allocated and freed at the same level of abstraction and, and ideally, in the same code module. This includes the use of the following memory allocation and deallocation functions described in subclause 7.23.3 of the C Standard [ISO/IEC 9899:2011]:

void *malloc(size_t size);

void *calloc(size_t nmemb, size_t size);

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

void *aligned_alloc(size_t alignment, size_t size);
 
void free(void *ptr);

Failing to follow this recommendation has led to real-world vulnerabilities. For example, freeing The affects of not following this recommendation are best demonstrated by an actual vulnerability. Freeing memory in different modules resulted in a vulnerability in MIT Kerberos 5 http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2004-002-dblfree.txt. The problem is the [MIT 2004]. The MIT Kerberos 5 code contains in this case contained error-handling logic, which frees freed memory allocated by the ASN.1 decoders if pointers to the allocated memory are were non-null. However, if a detectable error occursoccurred, the ASN.1 decoders themselves free freed the memory that they have had allocated. When some library functions receive received errors from the ASN.1 decoders, they also attempt attempted to free the same memory, causing resulting in a double-free vulnerability.

...

Noncompliant Code Example

...

This example demonstrates an error that can occur when memory is freed in different functions. First, an array of integers is dynamically allocated. The array, which is referred to by list and its size, number, are then passed to func2. If the number of elements in the array is greater than the value MIN_SIZE_ALLOWED, the array is processed. Otherwise, it is assumed an error has occurred, noncompliant code example shows a double-free vulnerability resulting from memory being allocated and freed at differing levels of abstraction. In this example, memory for the list array is allocated in the process_list() function. The array is then passed to the verify_size() function that performs error checking on the size of the list. If the size of the list is below a minimum size, the memory allocated to the list is freed, and the function returns . If the error occurs in func2, the dynamic memory referred to by list will be freed twice: once in func2 and again at the end of func1.to the caller. The calling function then frees this same memory again, resulting in a double-free and potentially exploitable vulnerability.

Code Block
bgColor #FFcccc lang c
enum {
Code Block
#define MIN_SIZE_ALLOWED 10 = 32 }; voidint func2verify_size(intchar *list, size_t list_size) { if (size < MIN_SIZE_ALLOWED) { /* Handle Errorerror Conditioncondition */ free(list); return -1; } /* Process list */return 0; } void func1 process_list(size_t number) { intchar *list = malloc (numberchar * sizeof)malloc(intnumber)); if (list == NULL) { /* Handle Allocationallocation Errorerror */ } func2if (verify_size(list, number) == -1) { free(list); return; } /* Continue Processingprocessing list */ free(list); }

...

The call to free memory in the verify_size() function takes place in a subroutine of the process_list() function, at a different level of abstraction from the allocation, resulting in a violation of this recommendation. The memory deallocation also occurs in error-handling code, which is frequently not as well tested as "green paths" through the code.

Compliant Solution

To correct this problem, the logic in the error-handling code should be changed in verify_size() is modified so that it no longer frees list. This change ensures that list is freed only once, in func1at the same level of abstraction, in the process_list() function.

enum {
#define MIN_SIZE_ALLOWED 10= 32 };

voidint func2(intverify_size(const char *list, size_t list_size) {
  if (size < MIN_SIZE_ALLOWED) {
     /* Handle Errorerror Conditioncondition */
    return  return-1;
  }
  /* Process list */return 0;
}

void func1 process_list(size_t number) {
  intchar *list = malloc (numberchar * sizeof(int))malloc(number);

  if (list == NULL) {
    /* Handle Allocationallocation Errorerror */
  }

  func2if (verify_size(list, number) == -1) {
      free(list);
      return;
  }

  /* Continue Processingprocessing list */

  free(list);
}

...

Risk Assessment

The mismanagement of memory can lead to freeing memory multiple times or writing to already freed memory. Both of these problems coding errors can result in an attacker executing arbitrary code with the permissions of the vulnerable process. Memory management errors can also lead to resource depletion and denial-of-service attacks.

Automated Detection

References

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

...

Image Added Image Added Image Added

...