Doubly freeing memory - Revision history

Christina Schelin: Merging Double Free into this article, since they're the same thing.

2018-12-29T15:22:06Z

Merging Double Free into this article, since they're the same thing.

Jmanico at 21:36, 28 July 2016

2016-07-28T21:36:55Z

Imifos at 12:36, 22 January 2016

2016-01-22T12:36:05Z

Imifos at 12:42, 2 December 2015

2015-12-02T12:42:43Z

KirstenS at 00:37, 21 February 2009

2009-02-21T00:37:04Z

KirstenS at 02:14, 18 February 2009

2009-02-18T02:14:56Z

KirstenS at 12:55, 30 October 2008

2008-10-30T12:55:07Z

KirstenS at 23:04, 23 September 2008

2008-09-23T23:04:58Z

Weilin Zhong at 20:50, 4 August 2006

2006-08-04T20:50:57Z

Pravir Chandra at 03:58, 28 May 2006

2006-05-28T03:58:32Z

@@ Line 1: / Line 1: @@
-{{Template:Vulnerability}}
+{{Template:Vulnerability}}{{Template:SecureSoftware}}{{Template:Fortify}}
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
@@ Line 6: / Line 5: @@
 ==Description==
-Freeing or deleting the same memory chunk twice may - when combined with other flaws - result in a write-what-where condition.
+Double free errors occur when free() is called more than once with the same memory address as an argument.
-'''Consequences'''
+Calling free() twice on the same value can lead to memory leak. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted and could allow a malicious user to write values in arbitrary memory spaces. This corruption can cause the program to crash or, in some circumstances, alter the execution flow.  By overwriting particular registers or memory spaces, an attacker can trick the program into executing code of his/her own choosing, often resulting in an interactive shell with elevated permissions.
 * Access control: Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.
-'''Exposure period'''
+=== 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'''
+=== Platform ===
 * Language: C, C++, Assembly
 * Operating system: All
-'''Required resources'''
+=== Required resources ===
 Any
-'''Severity'''
+=== Severity ===
 High
-'''Likelihood of exploit'''
+=== Likelihood of exploit ===
 Low to Medium
@@ Line 36: / Line 39: @@
 Doubly freeing memory can result in roughly the same write-what-where condition that the use of previously freed memory will.
-==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 that don't ship with heap-chunk check summing turned on.
 <pre>
@@ Line 65: / Line 68: @@
+}
 </pre>
 ==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.
-__NOTOC__
+==Related [[Attacks]]==
 [[Category:Vulnerability]]

@@ Line 3: / Line 3: @@
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==
@@ Line 37: / Line 35: @@
 Doubly freeing memory can result in roughly the same write-what-where condition that the use of previously freed memory will.
 ==Examples==
@@ Line 72: / Line 65: @@
+}
 </pre>
 ==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.
+* 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.
 __NOTOC__
 [[Category:Vulnerability]]
 [[Category:C/C++]]

@@ Line 130: / Line 130: @@
 [[Category:OWASP_CLASP_Project]]
 [[Category:Code Snippet]]
-[[Category:OWASP C/C++ Project]]
+[[Category:C/C++]]
 [[Category:Implementation]]

@@ Line 130: / Line 130: @@
 [[Category:OWASP_CLASP_Project]]
 [[Category:Code Snippet]]
-[[Category:C]]
+[[Category:OWASP C/C++ Project]]
 [[Category:Implementation]]

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:SecureSoftware}}
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
+[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 ==Description==

← Older revision		Revision as of 03:58, 28 May 2006
Line 77:		Line 77:
	* [[Write-what-where condition]]		* [[Write-what-where condition]]

−	~~==Categories ==~~

	[[Category:Vulnerability]]		[[Category:Vulnerability]]