Buffer overflows explained
If this has been talked about before, I'm sorry. I searched the site and did'nt see anything useful on buffer overflows, so I decided to write this up. I know when I first got into the field, buffer overflows were somewhat of a mystery to me. I always heard about them, but never had anyone explain it to me at a lower level. We'll here's my shot at doing just that. Hope this clears up some questions for the young security people, and opens the eyes of the sys admins.
Buffer overflows
Before I talk about the exploit stuff, let me define vulnerability…There are really 2 different definitions (everyone has different opinions on this). The first definition is a product flaw that allows something to circumvent the security of that product. If something is configured well but still has a security exposure, that is something the vender needs to fix! The other definition is “Anything” that offers the potential attack of a system. These are things like misconfigured systems, weak pw’s, permitting Net BIOS traffic from untrusted networks, using outdated systems with no user authentication (Win 95,98, Mac OS 6, ect..) and so on. Most vulnerabilities once made public are assigned a number and posted on the Common Vulnerabilities and Exposures database at http://cve.mitre.org
The exploit is something leveraging our first definition of a vulnerability against a system. One of the ways to do this is using a method call a buffer overflow. Just because a system has a vulnerability, that doesn’t mean it has been exploited yet. The CVE just lists vulnerabilities, and will say if there is a proof of concept or an actual working exploit, but they do not provide detail. Securityfocus.com hosts the Bugtraq mailing list which provides exploit details for vulnerabilities that have exploits.
What you can do with a buffer overflow
You can make a program crash, or the entire system. You can use the overflow to execute specific instructions using the system privileges of that program. Once in you can always easily escalate your privileges.
How vulnerable programs are exploited by a buffer overflow attack:
Usually the main part of the payload of buffer overflow exploit is shell code, but some attacks simply overwrite variables. A classic buffer overflow attack changes return address to point into shell code. The exploit overwrites return address and therefore EIP, then EIP is made to point back into exploit shell code. The return address can be pointed into a system library and load system routines. Most buffer overflows are stack based, the shell code is limited by the size of the stack. As an alternative, overflowing heap-based buffers allows more space for complex shell code.
Limitations
Not all buffer overflow vulnerabilities are equally exploitable. For instance buffers can be too small to hold usefull shell code, or too far away from a useable return address. Another possible limitation is the shell code. Shell code is processor specific. An exploit that may work on an Intel processor might crash a Sparc station. The actual discovery of a buffer overflow vulnerability will require a varying level of effort. Here are a few methods: Source code analysis – reverse engineering product into assembly instructions – good ‘ol brute force using a debugger to watch the programs behavior.
OS’s (insert M$ bashing here J)
I said shell code was processor specific, well it is also OS specific. Windows exploits have the Windows application program interface available. Unix makes use of different functions. The big challenge here is finding the buffers location on the stack and there are huge differences between Unix kernels. Also in Unix, shell code is usually padded with machine code “no operations”. Windows stack offsets however are consistent (Thanks Bill). This makes writing exploits a bit easier.
Finding Exploits
Some successful exploits like the ones developed by specific organizations or purposes remain private. Other exploits have become publicly available. That’s usually when the person who found it is so proud they want credit, or when someone is up mad that patches have’nt been created or applied. Some exploits require you to have a bit of skill. You have to compile and run exploits for most unix systems and usually the user must discover and enter the buffer’s stack offset. Other exploits are written and packaged nicely for the average 13 year old to run. This is especially true for Windows systems. They can be easily run by any script kiddie.
How to prevent a buffer overflow exploit
Close your eyes, cross your fingers and pray that the vender releases a patch. Once released, apply immediately!! You can modify the kernal to make the stack executable. This won’t stop heap based attacks and some legit programs might crash. You could also use application shims that intercept system calls (like eEyes SecureIIS). Or just practice using a more secure programming language like Java, ML, Hope or Lisp.
I love comments, bad or good, so fire away. (just to make it clear, I did provide a solution) :)
MC
