Difference between revisions of "Doubly freeing memory"

From OWASP
Jump to: navigation, search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
Freeing or deleting the same memory chunk twice may - when combined with other flaws - result in a write-what-where condition.
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
==Consequences ==
+
==Description==
  
* Access control: Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.
+
Freeing or deleting the same memory chunk twice may - when combined with other flaws - result in a write-what-where condition.
  
==Exposure period ==
+
'''Consequences'''
  
* Requirements specification: A language which handles memory allocation and garbage collection automatically might be chosen.
+
* Access control: Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.
  
* Implementation: Double frees are caused most often by lower-level logical errors.
+
'''Exposure period'''
  
==Platform ==
+
* 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.
  
* Language: C, C++, Assembly
+
'''Platform'''
  
* Operating system: All
+
* Language: C, C++, Assembly
 +
* Operating system: All
  
==Required resources ==
+
'''Required resources'''
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood of exploit ==
+
'''Likelihood of exploit'''
  
 
Low to Medium
 
Low to Medium
  
==Avoidance and mitigation ==
+
Doubly freeing memory can result in roughly the same write-what-where condition that the use of previously freed memory will.
  
* 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 ==
+
==Risk Factors==
  
Doubly freeing memory can result in roughly the same write-what-where condition that the use of previously freed memory will.
+
TBD
  
==Examples ==
+
==Examples==
  
 
While contrived, this code should be exploitable on Linux distributions which do not ship with heap-chunk check summing turned on.
 
While contrived, this code should be exploitable on Linux distributions which do not ship with heap-chunk check summing turned on.
Line 71: Line 73:
 
</pre>
 
</pre>
  
==Related problems ==
 
  
* [[Using freed memory]]
+
==Related [[Attacks]]==
 +
* [[Attack 1]]
 +
* [[Attack 2]]
  
* [[Write-what-where condition]]
 
  
 +
==Related [[Vulnerabilities]]==
 +
* [[Using freed memory]]
 +
* [[Write-what-where condition]]
  
[[Category:Vulnerability]]
 
  
[[Category:Range and Type Errors]]
+
==Related [[Controls]]==
 +
* 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.
  
 +
 +
==Related [[Technical Impacts]]==
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 +
 +
==References==
 +
TBD
 +
 +
[[Category:FIXME|add links
 +
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 +
Availability Vulnerability
 +
 +
Authorization Vulnerability
 +
 +
Authentication Vulnerability
 +
 +
Concurrency Vulnerability
 +
 +
Configuration Vulnerability
 +
 +
Cryptographic Vulnerability
 +
 +
Encoding Vulnerability
 +
 +
Error Handling Vulnerability
 +
 +
Input Validation Vulnerability
 +
 +
Logging and Auditing Vulnerability
 +
 +
Session Management Vulnerability]]
 +
 +
__NOTOC__
 +
 +
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Vulnerability]]
 +
[[Category:Range and Type Error Vulnerability]]
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]
 +
[[Category:Code Snippet]]
 +
[[Category:C]]
 +
[[Category:Implementation]]

Latest revision as of 19:37, 20 February 2009

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



Last revision (mm/dd/yy): 02/20/2009

Vulnerabilities Table of Contents

Description

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

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


Risk Factors

TBD

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 Attacks


Related Vulnerabilities


Related Controls

  • 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.


Related Technical Impacts


References

TBD