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 "Double Free"
m (Remove Java category (free doesnt exist in Java)) |
|||
| Line 2: | Line 2: | ||
{{Template:Fortify}} | {{Template:Fortify}} | ||
| − | + | [[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== | ==Description== | ||
| Line 12: | Line 18: | ||
Calling free() twice on the same value can lead to a buffer overflow. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack. | Calling free() twice on the same value can lead to a buffer overflow. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack. | ||
| − | ==Examples == | + | |
| + | ==Risk Factors== | ||
| + | |||
| + | * Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen | ||
| + | * Discuss the technical impact of a successful exploit of this vulnerability | ||
| + | * Consider the likely [business impacts] of a successful attack | ||
| + | |||
| + | |||
| + | ==Examples== | ||
The following code shows a simple example of a double free vulnerability. | The following code shows a simple example of a double free vulnerability. | ||
| Line 33: | Line 47: | ||
Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once. | Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once. | ||
| − | |||
| − | ==Related Attacks== | + | ==Related [[Attacks]]== |
| + | |||
| + | * [[Attack 1]] | ||
| + | * [[Attack 2]] | ||
| − | |||
| − | ==Related | + | ==Related [[Vulnerabilities]]== |
| − | + | * [[Vulnerability 1]] | |
| + | * [[Vulnerabiltiy 2]] | ||
| + | |||
| + | ==Related [[Controls]]== | ||
| + | |||
| + | * [[Control 1]] | ||
| + | * [[Control 2]] | ||
| + | |||
| + | |||
| + | ==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:Code Quality Vulnerability]] | [[Category:Code Quality Vulnerability]] | ||
| − | |||
[[Category:Implementation]] | [[Category:Implementation]] | ||
| − | |||
[[Category:Code Snippet]] | [[Category:Code Snippet]] | ||
Revision as of 22:56, 23 September 2008
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
- This article includes content generously donated to OWASP by
Last revision (mm/dd/yy): 09/23/2008
Vulnerabilities Table of Contents
Description
Double free errors occur when free() is called more than once with the same memory address as an argument.
Calling free() twice on the same value can lead to a buffer overflow. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.
Risk Factors
- Talk about the factors that make this vulnerability likely or unlikely to actually happen
- Discuss the technical impact of a successful exploit of this vulnerability
- Consider the likely [business impacts] of a successful attack
Examples
The following code shows a simple example of a double free vulnerability.
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);
Double free vulnerabilities have two common (and sometimes overlapping) causes:
- Error conditions and other exceptional circumstances
- Confusion over which part of the program is responsible for freeing the memory
Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.
Related Attacks
Related Vulnerabilities
Related Controls
Related Technical Impacts
References
TBD
