bugtraq - Re: smail remote and local root holes (no, really ;-)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 26 Mar 2005 16:31:39 -0500
From: sean <infamous41md@...pop.com>
To: "Greg A. Woods" <woods-smail@...nix.com>
Cc: bugtraq <bugtraq@...urityfocus.com>
Subject: Re: smail remote and local root holes (no, really ;-)


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