---

STACK'em UP !! -- a literature (not practical) on buffer-overflow Anoop Menon (Batch of 2004 IIITA) Software Engineer NetScaler Pvt. Ltd (Bangalore)

---

"The trouble with programmers is that you can never tell what a programmer is doing until it's too late" -- Seymour Cray

What you are going to read is not any novel idea that i am proposing. Its just sharing some information to those who might be interested in it. Its an old secret :-).

Well many of you must have heard of the BUFFER-OVERFLOW exploits. Some of you must already be knowing what they are. But i am pretty sure that a small percent of the geeky population in the world would actually write an entire BUFFER-EXPLOIT from the scratch. It requires heavy time and effort and is highly dependent on the architecture and memory organization of the target platform.

I have also just run some existing scripts available on the net to see how this entire theory gets working in practise. So i thought maybe sharing the theory with you guys who are not aware of it. This article is just a jist of the big picture and i shall give you references to atleast 2 good articles (outdated but informative) based on this subject. This article assumes that we are working on Intelx86 CPU.

As i said the 'BUFFER-OVERFLOW' technique is highly dependent on the architecture and memory organization of the target platform. Now coming to the MEMORY; it is divided into 3 parts:

a. Text - that area of the memory where the readonly(s) and executables reside
b. Data - that area of the memory where initialized and unintialized data that are required for the executing program reside
c. Stack - this you all would be familiar with, the temporary LIFO Storage that helps the processor manage program execution

---------------------- higher memory address

STACK

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

DATA

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

TEXT

---------------------- lower memory address

Now how many of you have heard the term 'FRAME' ?

I 'think' most of you would not have, but those who have tried some system level project(s) would have surely hit upon this term (ooh wait ! .. i guess in compilers course this thing is discussed isn't it ? ... i did not study anything for that subject during my college days :-d). All of you would have used functions/methods while writing your C/C++ programs right ?. Each invoked/called function has a portion on the stack which is called as Frame/Activation-record. The Frame contains information pertaining to 'return addresspointer', 'arguments that were passed into the function', 'address of the previous functions data'. So in short the stack consists of such logical stack FRAMES that are pushed when calling a function and popped when returning.

I am just referring to non-inline functions that are invoked. For functions that are 'inline' there are no stack operations performed and they are expanded inline at compile time (similar to MACROS which are expanded inline at preprocessor time, which takes place before compile time).

Local variables in the function are always allocated into registers when possible. When there are no registers available they are pushed onto the stack. Why is this done so ? - Registers < Stacks < Cache < Disk I/O is the order in which they get rated when it comes to access-time. Register access is the fastest. And it is for this very reason that the number of local variables that are used within functions should be kept to the bare minimum as possible. If possible you must reuse local variables using the preprocessor directives (#define, #undef). So when the local variables go on the stack they also become part of the
'FRAME'.

So typically in a function call your stack (Intel stacks grow downwards ... ADDing the stack pointer = POP .... SUBtracting the stack pointer = PUSH) would look like this:

<bottom of memory>
<top of memory>
<------------- <local variables> <base/frame pointer> <RET/return
addresspointer> <arguments to the function> --------------->
LOWER address
HIGHER Address

Now since the FRAME is organised such that the local data resides at a lower address region than the 'return addresspointer', overflowing the buffer with enough data will overwrite the critical 'return
addresspointer'. If an attacker can write executable code into the buffer (TEXT area), overflow the buffer with enough data to overwrite the 'return addresspointer' ....

and what does he overwrite it with ? .... simple ! ... overwrite it with an address that points to a location residing inside the executable code just written (remember the executable code he wrote into the TEXT area right ?). And this way he can execute any arbitary code on this system to which he has access to. In some cases the attacker overwrites the 'return addresspointer' with an address that points to an executable
shell script which may provide things that make his life merry. Now how he does all this is heavily dependent on how the OS that runs, the compiler, the ways certain system calls are implemented. So this is it - an abstract overview on Buffer Overflows. The following references will take you with examples, so .. happy learning !

References :

1. 'Smashing the Stack for Fun and Profit' --
http://www.cs.ucsb.edu/~jzhou/security/overflow.html
probably the most famous paper written on buffer overflow. Basic knowledge of assembly is required. An understanding of virtual memory concepts and experience with gdb can prove useful in understanding this article. This is explained for Intelx86 platform running Linux.

2. Apache 'Chunk Handling' Vulnerability