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"
Weilin Zhong (talk | contribs) |
|||
Line 2: | Line 2: | ||
{{Template:SecureSoftware}} | {{Template:SecureSoftware}} | ||
− | + | [[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]] | |
+ | |||
+ | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
+ | |||
+ | [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]] | ||
+ | |||
+ | [[ASDR Table of Contents]] | ||
+ | __TOC__ | ||
− | |||
− | == | + | ==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''' | |
− | * Operating system: All | + | * Language: C, C++, Assembly |
+ | * Operating system: All | ||
− | + | '''Required resources''' | |
Any | Any | ||
− | + | '''Severity''' | |
High | High | ||
− | + | '''Likelihood of exploit''' | |
Low to Medium | 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 == | + | ==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 72: | Line 79: | ||
</pre> | </pre> | ||
− | |||
− | * [[Using freed memory]] | + | ==Related [[Attacks]]== |
+ | * [[Attack 1]] | ||
+ | * [[Attack 2]] | ||
+ | |||
+ | |||
+ | ==Related [[Vulnerabilities]]== | ||
+ | * [[Using freed memory]] | ||
+ | * [[Write-what-where condition]] | ||
+ | |||
+ | |||
+ | ==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:Vulnerability]] | ||
[[Category:Range and Type Error Vulnerability]] | [[Category:Range and Type Error Vulnerability]] |
Revision as of 23:04, 23 September 2008
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
Last revision (mm/dd/yy): 09/23/2008
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