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
m |
|||
| Line 3: | Line 3: | ||
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
| − | |||
| − | |||
==Description== | ==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. | Doubly freeing memory can result in roughly the same write-what-where condition that the use of previously freed memory will. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Examples== | ==Examples== | ||
| Line 72: | Line 65: | ||
} | } | ||
</pre> | </pre> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Related [[Controls]]== | ==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__ | __NOTOC__ | ||
| − | |||
| − | |||
[[Category:Vulnerability]] | [[Category:Vulnerability]] | ||
| − | |||
| − | |||
| − | |||
[[Category:C/C++]] | [[Category:C/C++]] | ||
| − | |||
Revision as of 21:36, 28 July 2016
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
Last revision (mm/dd/yy): 07/28/2016
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.
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 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.
