MEM00-A. Allocate and free memory in the same module, at the same level of abstraction

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 double-free vulnerabilities, accessing freed memory, or writing to freed or unallocated memory.

To avoid these situations, it is recommended that memory be allocated and freed at the same level of abstraction, and ideally in the same code module.

Failing to follow this recommendation has lead to real-world vulnerabilities. For example, freeing memory in different modules resulted in a vulnerability in MIT Kerberos 5 MITKRB5-SA-2004-002 . 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 occured, 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, resulting in a double-free vulnerability.

Non-Compliant Code Example

This non-compliant code example illustrates 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 allocatd in the process_list() function. The array is then passed to the verify_list() 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 to the caller. The calling function then frees this same memory again, resulting in a double-free and potentially exploitable vulnerability.

int verify_size(char *list, size_t size) {
  if (size < MIN_SIZE_ALLOWED) {
    /* Handle Error Condition */
    free(list);
    return -1;
  }
  return 0;
}

void process_list(size_t number) {
  char *list = malloc(number);

  if (list == NULL) {
    /* Handle Allocation Error */
  }

  if (verify_size(list, number) == -1) {
    /* Handle Error */
  }

  /* Continue Processing list */

  free(list);
}

The call to free memory in the verify_list() 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 the error handling code in verify_list() is modified so that it no longer frees list. This change ensures that list is freed only once, at the same level of abstraction, in the process_list() function.

int verify_size(char *list, size_t size) {
  if (size < MIN_SIZE_ALLOWED) {
    /* Handle Error Condition */
    return -1;
  }
  return 0;
}

void process_list(size_t number) {
  char *list = malloc(number);

  if (list == NULL) {
    /* Handle Allocation Error */
  }

  if (verify_size(list, number) == -1) {
    /* Handle Error */
  }

  /* Continue Processing 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 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.

Related Vulnerabilities

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

References

[[ISO/IEC 9899-1999]] Section 7.20.3, "Memory Management Functions"
[[Seacord 05]] Chapter 4, "Dynamic Memory Management"
[[Plakosh 05]]
[MIT Kerberos 5 Security Advisory 2004-002 ]

Do not assume memory allocation routines initialize memory      08. Memory Management (MEM)       MEM01-A. Store a new value in pointers immediately after free()