On Fri, 25 Mar 2005 15:50:46 -0500 (EST)
"Greg A. Woods" <woods-smail@planix.com> 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 ]
