On Fri, 25 Mar 2005 15:50:46 -0500 (EST) "Greg A. Woods" <woods-smail@xxxxxxxxxx> wrote: > > Don't worry though -- it's definitely not exploitable. It's just > tripping one of smail's own self-defense mechanisms. > Since the call to xfree() comes so soon after the buffer is overflowed, > there's no chance to even try an exploit. The best you can do is kill > your own connection, leaving lots of evidence about your attempt and > where you connected from, including enough info to find and fix the bug. ;-) > * Program received signal SIGSEGV, Segmentation fault. * 0x4b70abe1 in mallopt () from /lib/libc.so.6 * (gdb) bt * #0 0x4b70abe1 in mallopt () from /lib/libc.so.6 * #1 0x4b709bf3 in malloc () from /lib/libc.so.6 * #2 0x0804d4fa in xmalloc () * #3 0x0807e6ed in verify_addr_form () * #4 0x0807f1a5 in verify_sender () * #5 0x08078928 in receive_smtp () * #6 0x080d8d9e in ?? () * #7 0x4b7b2840 in _IO_2_1_stdin_ () from /lib/libc.so.6 * #8 0xb0aba708 in ?? () * #9 0x080d899c in ?? () * #10 0x080ac635 in _IO_stdin_used () * #11 0x080d83f4 in ?? () * #12 0x080b6919 in _IO_stdin_used () * #13 0xb0aba6dc in ?? () * #14 0x4b7038f0 in _IO_file_setbuf () from /lib/libc.so.6 * Previous frame inner to this frame (corrupt stack?) * (gdb) x/i $pc * 0x4b70abe1 <mallopt+705>: mov %esi,0x8(%eax) * (gdb) i r eax esi * eax 0x41414141 1094795585 * esi 0x4b7b5854 1266374740 Moving a partially user controlled value into a totally user controlled address and you say 'definitely not exploitable?' That was from playing with this for a little bit of time. You're trying to tell me that a complete analysis of the process heap state won't yield root? -- [ sean ]
