This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Doubly freeing memory"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 +
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
Line 79: Line 80:
  
 
[[Category:Vulnerability]]
 
[[Category:Vulnerability]]
 
+
[[Category:Range and Type Error Vulnerability]]
[[Category:Range and Type Errors]]
 
 
 
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]
 +
[[Category:Code Snippet]]
 +
[[Category:C]]
 +
[[Category:Implementation]]

Revision as of 20:50, 4 August 2006

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


Overview

Freeing or deleting the same memory chunk twice may - when combined with other flaws - result in a write-what-where condition.

Consequences

  • Access control: Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.

Exposure period

  • Requirements specification: A language which handles memory allocation and garbage collection automatically might be chosen.
  • Implementation: Double frees are caused most often by lower-level logical errors.

Platform

  • Language: C, C++, Assembly
  • Operating system: All

Required resources

Any

Severity

High

Likelihood of exploit

Low to Medium

Avoidance and mitigation

  • Implementation: Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.

Discussion

Doubly freeing memory can result in roughly the same write-what-where condition that the use of previously freed memory will.

Examples

While contrived, this code should be exploitable on Linux distributions which do not ship with heap-chunk check summing turned on.

#include <stdio.h>
#include <unistd.h>

#define BUFSIZE1    512
#define BUFSIZE2    ((BUFSIZE1/2) - 8)

int main(int argc, char **argv) { 
  char *buf1R1;    
  char *buf2R1;    
  char *buf1R2;    

  buf1R1 = (char *) malloc(BUFSIZE2);    
  buf2R1 = (char *) malloc(BUFSIZE2);    
  
  free(buf1R1);    
  free(buf2R1);    

  buf1R2 = (char *) malloc(BUFSIZE1);    
  strncpy(buf1R2, argv[1], BUFSIZE1-1);    
  
  free(buf2R1);    
  free(buf1R2);
}

Related problems