Do not use, republish, in whole or in part, without the consent of the Author. TheTAZZone policy is that Authors retain the rights to the work they submit and/or post…we do not sell, publish, transmit, or have the right to give permission for such…TheTAZZone merely retains the right to use, retain, and publish submitted work within it’s Network

Buffer Overflows Part 2!

This is a continuation from my first Buffer Overflow Tutorial; I would highly recommend that you read that tut, before you read this one! (Even if you’ve read it before re-read it to refresh your memory!)

Ok, so in part one we looked at

How a Buffer Overflow happens and the security implications of this.
Ways to find what programs have SUID privileges using the

find / -type f –perm -04000 –ls command .

We also looked at how to change a program to give it #root privileges.

I will start this tutorial off at the point where, you have compiled a piece of code that is vulnerable to an overflow (see part 1), you have changed the ownership of the program to root and you have made it a SUID root program. We will call this program “pool”

So, we know pool can be exploited with a buffer overflow (as we programmed it) and we know it has root privileges (as we gave them to it)

Now what we need to do is generate a program with a buffer (remember a buffer is a portion of memory assigned to a program) that contains the shellcode, which will spawn a shell that can be “fed” into the pool program. We will call this program “snooker”

Our aim is to make the program pool overflow in to the buffer that the program snooker has given it and make the EIP point to where our shellcode within this buffer and then to make snooker accidentally execute this shellcode.

Obviously for this to work we need to know where our shellcode is stored in the buffer!

There two main ways of doing this: Using a NOP sled or by flooding the end of a buffer with quite a few “return addresses”.

No Operation (NOP)

As the name suggests this is an instruction that does nothing, its sole purpose is to take up a byte of memory so nothing else can occupy it.

Why is this useful to us?

For a few reasons really.

1. If our NOP is occupying a byte of memory we know that our shell code couldn’t possibly be there!
2. The processor will skip over a NOP until it gets to something that tells it to do something, i.e. our shellcode (hopefully)
3. A program wont crash if it hits a NOP as the NOP isn’t telling it to do anything, it will just move down or up to the next memory “block”

Consider this (each number represents a bock of memory in our buffer)

Pool Snooker Snooker Shellcode Snooker Snooker Snooker Snooker
1………..2…………3………….4………….5………….6………..7………….8…..
For us to execute our shellcode we would have to ensure the EIP was pointing at “4” and no where else, otherwise snooker would continue to run. There would be a lot of trial and error not to mention luck in executing the shell code!

But, what about if we done this:

Pool Snooker NOP NOP NOP NOP NOP Shellcode
….1……2……..3…….4…….5…….6…….7…….8
As long as the EIP was pointing at either 3,4,5,6,7 or 8 our shellcode would be executed, because as I said earlier the processor would just skip along them NOP’s until it got to something it could execute!
Obviously this gives us a bigger area of error for the EIP to execute the shellcode
So along as we overwrite the EIP with any address in the NOP we can be assured our shellcode will be executed

*The NOP sled is not limited in size, it can be 200+ bytes if you want it to be.
Use common sense though as if you fill the memory up with NOP’s then nothing is going to work!

Return Addresses:

The other way of doing it is with return address; this method can be and is, used in conjunction with the NOP method!

This is a very simple method.

All it does is “floods” the last part of our buffer with lots and lots of return address to where our shellcode or NOP is located.

Snooker Snooker NOP NOP NOP NOP Shellcode R/A7 R/A5 R/A3
…..1…………2…….3…….4…….5…..6……….7………..8…….9….10

So the return address (R/A) is telling the EIP to go to “7 , 5 or 3”

Have a look at the room for error we now have!
As long as the EIP is NOT pointing at 1 or 2 our shellcode is going to be executed

So compared to the first diagram:

Pool Snooker Snooker Shellcode Snooker Snooker Snooker Snooker
1………..2…………3………….4………….5………….6………..7………….8…..

Where we needed to hit “4” right on the head to execute our shellcode

Now all we need to do is make sure the EIP stays away from 1 + 2!

Of course both of these methods require us to know the approximate location of the buffer in the system memory!

How do we find this?

We find this by finding out where the current Stack Pointer is.
(Remember a stack pointer, amongst other things, is used to tell the EIP where to return to after a function has been completed), hence if we can control the stack pointer, we can control the EIP!!

In the snooker program them first place the stack will be telling the EIP to look at will be the start of the buffer, remember our shellcode is located in this buffer and we know how big the buffer is because we created it in our snooker program, so already we have a rough idea where our shellcode will be!

I feel it may be starting to get confusing, so I will break it all down:

We have:

1. Created a program that is susceptible to Buffer Overflows called Pool
2. Made Pool run with root privileges, so that, when we make it spawn a shell, the shell will have the same privileges (#root)
3. Created a program called Snooker, which gave pool a buffer, containing the shellcode to be executed.
4. Filled this buffer with NOP’s and Return Addresses, to maximise the chance of getting the shellcode to be run.
5. Found out where snookers buffer is by using the current stack pointer
6. We know how many bytes pool will take up, so when we coded (programmed) snooker we leave the first bytes free that pool will require to run, then we put some NOP’s to leave space between pool and our shellcode, this increases the %age of our shellcode executing
7. Filled the end of the buffer with return address that point to the NOP’s that are after pool.

So Pool overflows, the EIP will go where ever it likes in snookers buffer, if we are lucky it goes straight to the shellcode and spawns a root shell for us.
If we are unlucky it lands on a NOP, it then goes to the next NOP and the next and the next until it comes to our shell code and spawns a root shell!
Or, it land on a return address, which is telling it to go to either a NOP or if we are lucky again, the shellcode, if it goes to the shellcode, happy days we get a root shell, if it goes to a NOP, it slides down and down and down until low and behold….. yup, we get a root shell!

Did it make scene to anyone??

•This is a very very simplified version of it.
•There is a bit more to finding our buffer using stack pointer offsets, but I will cover this in a future tutorial!
•Again I have took liberties with memory addressing, just to keep it simple
•In Part 1 Snooker was called vuln but I felt like renaming it for this tut!
•I have has a few pm’s from people asking how to compile the code from my last tutorial, hence my next one will be about how to do that using Linux and a Windows based compiler.

Please bear in mind that this is a simplified version and liberties have been taken!

I hope you enjoyed reading it and maybe learnt something from it; I’m now off to buy me a big bottle of JD as I’ve drank a whole one whilst typing this! (Thank god for spell checkers!)

Thanks!
Nokia

Do not use, republish, in whole or in part, without the consent of the Author. TheTAZZone policy is that Authors retain the rights to the work they submit and/or post…we do not sell, publish, transmit, or have the right to give permission for such…TheTAZZone merely retains the right to use, retain, and publish submitted work within it’s Network

Buffer Overflows – what they are and how they work.

This can be quite a complicated issue, so I will try to break it down into different parts and put it into everyday language.

I will assume that if you are reading this you understand a little programming (functions, integers etc)

To understand buffer overflows it helps to know a bit about how a program utilizes memory.

First it will help to understand what an EIP is:

[it is essential to understand an EIP to understand how a buffer overflow works]

EIP:
Extended Instruction Pointer.

The processor has a very small chunk of memory itself, divided into what is called registers.
The most common register is the EIP; this tells the processor where to look in the system memory for the function (or piece of code) that it has to execute.

I.e. the code could be to print the word TAZZone on to your monitor and has been written to the memory at the address of 0×12345678. (Memory uses the hex numbering system).
The EIP would now tell the processor to go to 0×12345678 and do what ever the code is telling it to do, hence the word “TAZZone” will be printed on the screen.

Program memory:

There are five types of program memory, text, heap, stack, bss and data.
Each one of these is a special piece of memory reserved for a certain type of purpose.

I will cover text and stack for the purpose of this paper.

Text:

This is where the compiled machine language is stored. Write permissions are disabled here as it is used only to store the code, which is being executed.

When you compile a program, what you are doing is converting it from human readable form into a language the computer understands, it is the output of a compiled program that is stored in the text segment)

So for a very simplified example say you wanted to print the words Hello, goodbye, thank you, and Microsoft rules

(For ease I will use 1,2,3,4,5 etc for memory addresses instead of the correct addresses.

So hello is stored at 1, goodbye at 2, thank you at 3 and Microsoft rules at 4.
Here is what the processor will do

1. Get the address for the first function to complete from the EIP and go there
2. Add the number of bytes in the instruction to the EIP
3. Do what ever the piece of code is telling it to do, (print Hello.)
4. Go back to the EIP to get the next address.

The EIP will know when the instruction has been completed because in step 2 the processor told it how many bytes there was.

Stack:

The stack memory is used as a tempory storage space for functions.

When a function (print) is called by a program it will have its own variables (hello,goodbye,thank you etc)

and the code will be at a different place in the text segment of memory.

(I.e. hello cannot be at the same memory address as goodbye otherwise they would over write each other.)

So the function is to print Hello (1) Goodbye (2) and Thank you (3)

The whole function will be read from the text segment and get passed to the stack segment.
The stack segment will remember the addresses (1,2,3) of each variable and pass this data to the EIP to tell it which memory address to return to when the function is finished.

There is a lot more to the stack segment but it’s not really relevant at this point!

BUFFER OVERFLOWS

Ok, so the programmer has specified that the word Hello with need 5 bytes of memory, but what happens when 7 characters try to write them selves to this piece of memory instead, the word goodbye for example:

|H|E|L|L|O| – No probs here
1 2 3 4 5

|G|O|O|D|B| —— |Y|E| – | – | – | – They overflow into memory held for something else
-1- 2- 3-4-5 —— -6- 7- 8- 9 – 0

5 bytes are allocated but the variable was 7 bytes long. Now it can’t just disappear, it has to be written somewhere so a buffer overflow occurs. If the data that was overwritten in 6 + 7 were a critical part of the program, the program would have crashed.

Here is a well know piece of code to cause a buffer overflow (its very well known and is in most books about the subject, so know one jump on my back for posting it, please)

Code: Select all

Void overflow_function (char *str)

{

char buffer[20];            // size of the buffer is 20 bytes

strcpy(buffer, str);

}

int main()

{

char big_string[128];

int I;

for(i=0; I < 128; i++0                          // this makes it loop 128 times

}

big_string[i] = ‘A’;                             // Fill the big_string with AAAAA’s

}

overflow_function(big_string);

exit(0);

}

There are a few subtle things left out here, (unlucky skiddies), it should be easy for someone to fix who has a basic knowledge of C.

This program should crash as a result of the overflow

How can this be utilized to take control of a program?

Refer to the sample code above, 128 bytes where wrote to a space 20 bytes big.

The remaining 108 bytes overflow overwriting amongst other things the return address for the EIP, so now the EIP aint got a scoobie doo where to go and the program can no longer carry on so it just stops.

BUT, what if the return address was overwrote with an address of your choosing????

An address that contained code to be run?????

The program wouldn’t crash because as far as the processor is concerned its just gone to the next part of the program, it doesn’t know what’s meant to come next, it just reads what’s there and does what it says

What if the return address that you have specified to the EIP, contains information that a user has entered into your program?

So your program could have been to get someone to type their name and then make it print out on the screen.

But the user doesn’t type his name; instead he has typed a small piece of shellcode!

Say, you know where this input is stored so you cause a buffer overflow in your code on purpose, one that give the return address for the EIP as the address the user input is stored (user name)
The EIP will now tell the processor to go here and execute the shellscript that is there.

Shellcode is bytecode that just spawns a shell.

Now say a SUID program with root privileges was made to spawn a shell, the shell that was spawned would have the same privileges as the program (#root!)

How do you find out what SUID files have root??

find / -type f –perm -04000 –ls – this will list all suid programs with root privileges on *nix systems.

The following code is taken from the book: Hacking, the art of exploitation

Code: Select all

vuln.c code

Int main(int argc, char *argv[])

{

char buffer[500];

strcpy(buffer, argv[1]);

return 0;

}

This code just miss-manages memory, but if the ownership was changed to root and was changed to a suid root program that is susseptable to buffer overflows (Bugtraq!!)

$ sudo chown root vuln
$ sudo chmod +s vuln
$ ls –l vuln

-rwsr-sr-x 1 root users etc

vuln is now a root suid program.

Now all you need is code to make a buffer containing the shellcode to be fed to the vuln program that will overwrite the return address to execute the shellcode.

Obviously the address of the shellcode must be known in advance – this is a tutorial in itself though.

I do have the code required to create a buffer to be fed to the vuln program to on some systems trick it into executing shellcode when it crashes, hence, spawning a #root shell for the user to do as he wishes

However I am not going to post it here, if you would like it PM me!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

*I did take a few liberties with how code, functions memory addressing etc works just for the sake of keeping it simple.

There is a hell of a lot more to buffer overflows and loads of different types; I have covered “Stack Based Overflows” here.