A5 2004 Buffer Overflow - Revision history

Wichers at 22:49, 20 April 2010

2010-04-20T22:49:04Z

KirstenS: Protected "A5 2004 Buffer Overflow" [edit=sysop:move=sysop]

2008-10-10T12:18:38Z

Protected "A5 2004 Buffer Overflow" [edit=sysop:move=sysop]

KirstenS: /* Examples and References */

2008-10-09T20:27:13Z

‎Examples and References

KirstenS: /* Examples and References */

2008-10-09T20:26:53Z

‎Examples and References

KirstenS at 20:25, 9 October 2008

2008-10-09T20:25:55Z

KirstenS at 14:43, 9 October 2008

2008-10-09T14:43:43Z

KirstenS: New page: === Description=== Attackers use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the w...

2008-10-09T13:52:57Z

New page: === Description=== Attackers use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the w...

New page

=== Description===

Attackers use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code – effectively taking over the machine. Buffer overflows are not easy to discover and even when one is discovered, it is generally extremely difficult to exploit. Nevertheless, attackers have managed to identify buffer overflows in a staggering array of products and components. Another very similar class of flaws is known as format string attacks.
Buffer overflow flaws can be present in both the web server or application server products that serve the static and dynamic aspects of the site, or the web application itself. Buffer overflows found in widely used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images, they open themselves to potential buffer overflow attacks.

Buffer overflows can also be found in custom web application code, and may even be more likely given the lack of scrutiny that web applications typically go through. Buffer overflow flaws in custom web applications are less likely to be detected because there will normally be far fewer hackers trying to find and exploit such flaws in a specific application. If discovered in a custom application, the ability to exploit the flaw (other than to crash the application) is significantly reduced by the fact that the source code and detailed error messages for the application are normally not available to the hacker.

===Environments Affected===

Almost all known web servers, application servers, and web application environments are susceptible to buffer overflows, the notable exception being Java and J2EE environments, which are immune to these attacks (except for overflows in the JVM itself).

===Examples and References===

* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: Data Validation http://www.owasp.org/documentation/guide/
* Aleph One, “Smashing the Stack for Fun and Profit”, http://www.phrack.com/show.php?p=49&a=14
* Mark Donaldson, “Inside the Buffer Overflow Attack: Mechanism, Method, & Prevention”, http://rr.sans.org/code/inside_buffer.php

===How to Determine If You Are Vulnerable===

For server products and libraries, keep up with the latest bug reports for the products you are using. For custom application software, all code that accepts input from users via the HTTP request must be reviewed to ensure that it can properly handle arbitrarily large input.

===How to Protect Yourself===
Keep up with the latest bug reports for your web and application server products and other products in your Internet infrastructure. Apply the latest patches to these products. Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.
For your custom application code, you need to review all code that accepts input from users via the HTTP request and ensure that it provides appropriate size checking on all such inputs. This should be done even for environments that are not susceptible to such attacks as overly large inputs that are uncaught may still cause denial of service or other operational problems.

← Older revision		Revision as of 22:49, 20 April 2010
Line 25:		Line 25:
	Keep up with the latest bug reports for your web and application server products and other products in your Internet infrastructure. Apply the latest patches to these products. Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.		Keep up with the latest bug reports for your web and application server products and other products in your Internet infrastructure. Apply the latest patches to these products. Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.
	For your custom application code, you need to review all code that accepts input from users via the HTTP request and ensure that it provides appropriate size checking on all such inputs. This should be done even for environments that are not susceptible to such attacks as overly large inputs that are uncaught may still cause denial of service or other operational problems.		For your custom application code, you need to review all code that accepts input from users via the HTTP request and ensure that it provides appropriate size checking on all such inputs. This should be done even for environments that are not susceptible to such attacks as overly large inputs that are uncaught may still cause denial of service or other operational problems.
		+
		+	[[Category:OWASP Top Ten Project]]

← Older revision		Revision as of 14:43, 9 October 2008
Line 1:		Line 1:
		+	''This article is for the OWASP Top 10 2004''
		+
		+
	=== Description===		=== Description===

← Older revision	Revision as of 12:18, 10 October 2008
(No difference)

@@ Line 15: / Line 15: @@
 ==Examples and References==
 * OWASP Guide to Building Secure Web Applications and Web Services,  [[Data_Validation|Data Validation]]
 ==How to Determine If You Are Vulnerable==

@@ Line 2: / Line 2: @@
-=== Description===
+==Description==
 Attackers use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code – effectively taking over the machine. Buffer overflows are not easy to discover and even when one is discovered, it is generally extremely difficult to exploit. Nevertheless, attackers have managed to identify buffer overflows in a staggering array of products and components. Another very similar class of flaws is known as format string attacks.
@@ Line 9: / Line 9: @@
 Buffer overflows can also be found in custom web application code, and may even be more likely given the lack of scrutiny that web applications typically go through. Buffer overflow flaws in custom web applications are less likely to be detected because there will normally be far fewer hackers trying to find and exploit such flaws in a specific application. If discovered in a custom application, the ability to exploit the flaw (other than to crash the application) is significantly reduced by the fact that the source code and detailed error messages for the application are normally not available to the hacker.
-===Environments Affected===
+==Environments Affected==
 Almost all known web servers, application servers, and web application environments are susceptible to buffer overflows, the notable exception being Java and J2EE environments, which are immune to these attacks (except for overflows in the JVM itself).
-===Examples and References===
+==Examples and References==
 * OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: Data Validation http://www.owasp.org/documentation/guide/
@@ Line 19: / Line 19: @@
 * Mark Donaldson, “Inside the Buffer Overflow Attack: Mechanism, Method, & Prevention”, http://rr.sans.org/code/inside_buffer.php
-===How to Determine If You Are Vulnerable===
+==How to Determine If You Are Vulnerable==
 For server products and libraries, keep up with the latest bug reports for the products you are using. For custom application software, all code that accepts input from users via the HTTP request must be reviewed to ensure that it can properly handle arbitrarily large input.
-===How to Protect Yourself===
+==How to Protect Yourself==
 Keep up with the latest bug reports for your web and application server products and other products in your Internet infrastructure. Apply the latest patches to these products. Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.
 For your custom application code, you need to review all code that accepts input from users via the HTTP request and ensure that it provides appropriate size checking on all such inputs. This should be done even for environments that are not susceptible to such attacks as overly large inputs that are uncaught may still cause denial of service or other operational problems.