Where can I find a demonstration of a buffer overflow?

Question

Is there a site, or is there a simple way of setting up one, which demonstrates what can happen with a buffer overrun? This is in the context of a web app.

Answer 1

They tend not to occur in web apps. Google's Web Application Exploits and Defenses codelab has a short section on it but doesn't demonstrate it:

This codelab doesn't cover overflow vulnerabilities because Jarlsberg is written in Python, and therefore not vulnerable to typical buffer and integer overflow problems. Python won't allow you to read or write outside the bounds of an array and integers can't overflow. While C and C++ programs are most commonly known to expose these vulnerabilities, other languages are not immune. For example, while Java was designed to prevent buffer overflows, it silently ignores integer overflow.

It really depends on the language you're using as to whether buffer overflow is even possible.

Answer 2

The first question is... what webserver or library? IIS-6 running the ASP script interpreter? ASP.NET behind IIS-7? Apache Tomcat? Some library like the HTTPServer in Poco?

To exploit a buffer overrun you must first find a specific place in an application where the overrun can occur, and then figure out what exact bytes must be sent to overwrite memory with the right bytes to run out to the stack and then execute machine code you've sent in the overrun (because you've rewritten the stack).

http://en.wikipedia.org/wiki/Buffer_overflow

http://seclists.org/fulldisclosure/2005/Apr/412

http://www.microsoft.com/technet/security/bulletin/MS06-034.mspx

http://www.owasp.org/index.php/Buffer_Overflow

http://www.windowsecurity.com/articles/Analysis_of_Buffer_Overflow_Attacks.html

Bring on the flames, but I would say that any codebase of sufficient size contains potentially explotable buffer overflows regardless of the execution environment or source language. Sure, some languages and platforms allow the app developers to "shoot themselves in the foot" easier than others, but it all comes down to individual dilligence, project complexity, use of 3rd-party code and then there are always exploits for base implementations.

Buffer overruns are here to stay, it's just a question of mitigating exposure through safe programming practices and diligently monitoring for new exploits as they are discovered to manage risk.

A grand example is that for a web app, there's the chance for overflows in the networking implementations of all the equipment and applications handling delivery of your bytes across the Internet.

Consider the distinction of a client trying to break a server, versus one client trying to conquer other clients accessing a specific server?

Besides the simple "C" style overruns where the developer failed to follow secure programming practices, there are hidden gems like integer overflows.

Even if a certain server host environment is known to be highly stable, it no doubt makes use of a database and other operating system facilities which themselves might be exploitable through the webserver.

When you get right down to it, nothing is secure and it's really just a matter of complexity.

The only way a specific application or server can be fully secure is through diligent monitoring so issues can be corrected when questionable behavior is discovered. I highly doubt Walmart or Fedex or any other major corporation is happy to publicize breaches. Instead they monitor, fix and move on.

One could even say that SQL Injection is an abstract form of a buffer overrun, but you're simply picking where you want the buffer to end using specific characters and then providing the code you wish to execute in the right place.