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 "Buffer overflow"
| Line 2: | Line 2: | ||
<<! marked for deletion because it's a duplicate>> | <<! marked for deletion because it's a duplicate>> | ||
| − | #REDIRECT [[Buffer Overflow]] | + | #REDIRECT [[Buffer Overflow]] |
==Overview== | ==Overview== | ||
Revision as of 16:09, 11 April 2009
<<! marked for deletion because it's a duplicate>>
#REDIRECT Buffer Overflow
Overview
A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers.
Consequences
- Category:Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
- Access control (instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program’s implicit security policy.
- Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service.
Exposure period
- Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
- Design: Mitigating technologies such as safe-string libraries and container abstractions could be introduced.
- Implementation: Many logic errors can lead to this condition. It can be exacerbated by lack of or mis¬use of mitigating technologies.
Platform
- Languages: C, C++, Fortran, Assembly
- Operating platforms: All, although partial preventative measures may be deployed, depending on environment.
Required resources
Any
Severity
Very High
Likelihood of exploit
High to Very High
Avoidance and mitigation
- Pre-design: Use a language or compiler that performs automatic bounds checking.
- Design: Use an abstraction library to abstract away risky APIs. Not a complete solution.
- Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio / GS flag. Unless this provides automatic bounds checking, it is not a complete solution.
- Operational: Use OS-level preventative functionality. Not a complete solution.
Discussion
Buffer overflows are one of the best known types of security problem. The best solution is enforced run-time bounds checking of array access, but many C/C++ programmers assume this is too costly or do not have the technology available to them. Even this problem only addresses failures in access control — as an out-of-bounds access is still an exception condition and can lead to an availability problem if not addressed.
Some platforms are introducing mitigating technologies at the compiler or OS level. All such technologies to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is more common to make the workload of an attacker much higher — for example, by leaving the attacker to guess an unknown value that changes every program execution.
Examples
There are many real-world examples of buffer overflows, including many popular “industrial” applications, such as e-mail servers (Sendmail) and web servers (Microsoft IIS Server).
In code, here is a simple, if contrived example:
void example(char *s) {
char buf[1024];
strcpy(buf, s);
}
int main(int argc, char **argv) {
example(argv[1]);
}
Since argv[1] can be of any length, more than 1024 characters can be copied into the variable buf.
