Difference between revisions of "Buffer overflow"

From OWASP
Redirect page
Jump to: navigation, search
(Redirected page to Buffer Overflows)
 
Line 1: Line 1:
{{template:CandidateForDeletion}}
+
#REDIRECT [[Buffer_Overflows]]
 
+
<<! 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:
+
 
+
<pre>void example(char *s) {
+
  char buf[1024];
+
  strcpy(buf, s);
+
}
+
int main(int argc, char **argv) {
+
  example(argv[1]);
+
}</pre>
+
 
+
Since argv[1] can be of any length, more than 1024 characters can be copied into the variable buf.
+
 
+
==Related problems ==
+
 
+
* [[Stack overflow]]
+
 
+
* [[Heap overflow]]
+
 
+
* [[Integer overflow]]
+
 
+
==How to test ==
+

Latest revision as of 15:49, 3 September 2014