BugTraq
Re: smail remote and local root holes (no, not really ;-) Mar 25 2005 08:50PM
Greg A. Woods (woods-smail planix com) (2 replies)
Re: smail remote and local root holes (really, it is exploitable) Mar 28 2005 04:42AM
sean (infamous41md hotpop com)
Re: smail remote and local root holes (no, really ;-) Mar 26 2005 09:31PM
sean (infamous41md hotpop com)
On Fri, 25 Mar 2005 15:50:46 -0500 (EST)
"Greg A. Woods" <woods-smail (at) planix (dot) com [email concealed]> 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 ]

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus