Buffer overflows explained
Results 1 to 5 of 5

Thread: Buffer overflows explained

  1. #1
    Member
    Join Date
    Feb 2003
    Posts
    53

    Post 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

  2. #2
    Senior Member
    Join Date
    Aug 2001
    Posts
    503
    Well-written post. I think you did a pretty good job of explaining what a buffer overflow is without showing specifically how to create one. Very good.

    *tips hat*
    --PhirePhreak
    I know you\'re out there. I can feel you now. I know that you\'re afraid. You\'re afraid of us. You\'re afraid of change. I don\'t know the future. I didn\'t come here to tell you how this is going to end. I came here to tell you how it\'s going to begin. I\'m going to hang up this phone, and then I\'m going to show these people what you don\'t want them to see. I\'m going to show them a world without you, a world without rules and controls, without borders or boundaries. A world where anything is possible. Where we go from there is a choice I leave to you.

  3. #3
    Member
    Join Date
    Feb 2003
    Posts
    53
    Is it a bad thing to actually show the "nuts and bolts" of a buffer overflow? I was actually thinking as a part2 to this to show an outdated buffer overflow, the exact CVE# it went after, how it worked and how it was fixed. Kinda present it as a case study. I guess that wouldn't go over well here?

  4. #4
    Senior Member
    Join Date
    Nov 2001
    Posts
    472
    Oh yes it would. I'm very interested! Greenies for you if you post it!
    ---
    proactive

  5. #5
    Senior Member
    Join Date
    Apr 2003
    Posts
    103
    Nice post. I would be interested some shell code examples. That would be very interesting.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •