On Tue, May 20, 2003 at 05:19:16PM -0600, Aaron Adams wrote:
> I have not been able to figure out why 0x4 and 0x5 will trigger a segfault
> during the second free() as I would expect their behavior to mimic those
> values above. Especially since they also only consume the 3 least
> significant bits of buf2 [SIZE]. Any takers?
Well, here is what's happening during the second free() in glibc-2.3.1 anyway:
(gdb) n
3333 ar_ptr = arena_for_chunk(p);
(gdb) x/4i$pc
0x40092c64 <__libc_free+84>: and $0x4,%edx
0x40092c67 <__libc_free+87>: je 0x40092cb2 <__libc_free+162>
0x40092c69 <__libc_free+89>: and $0xfff00000,%eax
0x40092c6e <__libc_free+94>: mov (%eax),%edi
(gdb) i r edx eax
edx 0x104 260
eax 0x8049bd0 134519760
(gdb)
Relevant snippets of code:
arena.c:
#define heap_for_ptr(ptr) \
((heap_info *)((unsigned long)(ptr) & ~(HEAP_MAX_SIZE-1)))
#define arena_for_chunk(ptr) \
(chunk_non_main_arena(ptr) ? heap_for_ptr(ptr)->ar_ptr : &main_arena)
malloc.c:
#define NON_MAIN_ARENA 0x4
/* check for chunk from non-main arena */
#define chunk_non_main_arena(p) ((p)->size & NON_MAIN_ARENA)
0x4 and 0x5 both have the NON_MAIN_ARENA-bit set in the chunk size,
which is stored in register %edx in the asm-dump from gdb shown above.
As you probably have figured out, the pointer p is stored in %eax and
is a pointer to the start of the chunk, e.g. the pointer returned by
malloc(), minus 8.
Thus, if the NON_MAIN_ARENA-bit is set (size & 4), chunk_non_main_arena(ptr)
evaluates to a non-zero value (namely, 4) and arena_for_chunk(p) is evaluated
to heap_for_ptr(ptr)->ar_ptr.
As you can see in the definition of heap_for_ptr() it will locate the heap_info
struct by doing bitwise-anding ptr with ~(HEAP_MAX_SIZE-1). HEAP_MAX_SIZE is
defined to 1024*1024 = 1048576. With a little bash-magic we'll find out this:
[je@vudo ~]$ printf "%08x\n" $[~(1024*1024-1)&0xffffffff]
fff00000
Which explains this:
0x40092c69 <__libc_free+89>: and $0xfff00000,%eax
And since %eax = p = 0x8049bd0 bitwise-anded with 0xfff00000 is 0x08000000
we get a segmentation fault when trying to move a word of data from that,
unmapped, address. That is, when the following is executed:
0x40092c6e <__libc_free+94>: mov (%eax),%edi
Btw, was I excluded from the summary because of my sarcastic comments towards
the majority of the readers, that thought the idea of the challenge was to find
the rather obvious faulty for-loop or because you overlooked my exploit when
summarizing the thread?
Anyway, here's a helper for my exploit for the dummies out there:
#!/bin/bash
[ $# -ge 1 ] && VULN=$1 || VULN=./vulndev-1; shift
[ $# -ge 1 ] && EXPL=$1 || EXPL=./expldev-1; shift
ADDR=`printf "0x%08X" $[0x$(objdump -R $VULN | awk '$3 == "free" { print $1 }') - 8]`
exec $EXPL $VULN $ADDR
For the actual exploit, look in the archives.
> Aaron Adams
--
Joel Eriksson <jeat_private>
-------------------------------------------------
Cellphone: +46-70-288 64 16 Home: +46-26-10 23 37
Security Research & Systems Development at Bitnux
PGP Key Server pgp.mit.edu, PGP Key ID 0x529FDBD1
A615 A1E1 3CA2 D7C2 CFEA 47B4 7EF7 E6B2 529F DBD1
-------------------------------------------------
This archive was generated by hypermail 2b30 : Wed May 21 2003 - 08:26:47 PDT