Buffer Overflows
by Joel R. Voss aka. Javantea
jvoss@altsci.com
jvoss@myuw.net
July 2, 2006

This essay is not finished, but will be in 1 week. Check back Sept 16.

DESCRIPTION

Trivial buffer overflows are easy to exploit with the right tools. Aleph released several buffer overflow tools with his remarkable article "Smashing The Stack For Fun And Profit" in Phrack 49. Recent advances in security technologies have made these more difficult, but junior programmers will continue to make these vulnerabilities far into the future. Interpreted languages promise ensured memory, but programs compiled to bytecode will have these problems. Simple security checking can solve buffer overflows by bounds checking and using functions that take into account the size of the destination buffer. The book, Sockets, Shellcode, Coding, and Porting notes that sadly buffer overflows are history in professional coding (heap overflows have a long ways to go though). That may be true in open source software, but in megacorporations and non-professional coding, bugs will remain. Commonly these program will have networking built-in and will be run as root (or suid).

The trick to understanding what the buffer overflow code is doing is found in a few small things that you have to try yourself. Break out buffovr1-0.1.tgz for this. If you don't feel like running buffer overflows on your box, then find someone else's box.
The most simple that you should know already is that a segfault is when you try to read memory that your process doesn't have access to. The kernel knows where you are allowed to read and jump to, so if you get a segfault, you've got some type of buffer/heap overflow.
The second one equally easy is that variables in a program are pushed onto the stack. If you're defining variables, you're pushing stuff on the stack.
The third idea is absurdly easy: when you write 200 bytes into a 128 byte buffer on the stack, it will overwrite variables.
The fourth idea is interesting, but easy to see when you're looking at the code: One of the variables that you don't push manually is the sfp which is jumped to by the ret opcode. That way we are able to jump to our shellcode in the buffer.
The fifth idea is pretty interesting: how do we know where the buffer is? If we have access to the computer, we can just grab the current stack pointer and add a few. But if not, we can check a similar computer or guess.

If you're running Linux kernel 2.6.12+ (I hope you are), then you have some stack pointer protection, which will make the exploit segfault instead of exploit on the first try. Next month will feature a full article on various memory address randomization security systems and how to crack them. Lemme say for now, you can get the exploit to work by running the program in a while loop (even if that's ugly as heck).

METHOD

USAGE







If you are interested in developing Buffer Overflows, feel free to e-mail me.

Back

Permalink

Comments: 0

Leave a reply »

 
  • Leave a Reply
    Your gravatar
    Your Name