full-disclosure - Re: Fwd: VSFTPD Remote Heap Overrun (low severity)

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Mon, 12 Dec 2011 11:39:01 -0500
From: Daniel J Walsh <dwalsh@...hat.com>
To: Ramon de C Valle <rcvalle@...hat.com>
Cc: "HI-TECH ." <isowarez.isowarez.isowarez@...glemail.com>,
	full-disclosure@...ts.grok.org.uk
Subject: Re: Fwd: VSFTPD Remote Heap Overrun (low severity)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/12/2011 11:22 AM, Ramon de C Valle wrote:
>> I havent looked into it yet, just saw the 0x41414141 in the
>> registers and assumed it is exploitable.I will have a look into
>> it when I find time and post the results here.
> Just some additional information about what probably happened in
> your case, and why I've asked if this behaviour is consistent.
> 
> In Red Hat Enterprise Linux 6, vsftpd-2.2.2, and glibc 2.12:
> 
> [...]
> 
> (gdb) c Continuing.
> 
> Program received signal SIGABRT, Aborted. 0x009c2424 in
> __kernel_vsyscall () (gdb) bt #0  0x009c2424 in __kernel_vsyscall
> () #1  0x001bdd31 in raise () from /lib/libc.so.6 #2  0x001bf60a in
> abort () from /lib/libc.so.6 #3  0x001fbd5d in __libc_message ()
> from /lib/libc.so.6 #4  0x002021a1 in malloc_printerr () from
> /lib/libc.so.6 #5  0x00222ca3 in __tzfile_read () from
> /lib/libc.so.6 #6  0x00222348 in tzset_internal () from
> /lib/libc.so.6 #7  0x00222491 in __tz_convert () from
> /lib/libc.so.6 #8  0x0022078f in localtime () from /lib/libc.so.6 
> #9  0x00180f1d in ?? () #10 0x001769de in ?? () #11 0x00176cb8 in
> ?? () #12 0x001701aa in ?? () #13 0x00172758 in ?? () #14
> 0x0017a46e in ?? () #15 0x0017a937 in ?? () #16 0x0016d58d in main
> () (gdb) f 5 #5  0x00222ca3 in __tzfile_read () from
> /lib/libc.so.6 (gdb) i r eax            0x0	0 ecx            0x53e
> 1342 edx            0x6	6 ebx            0x319ff4	3252212 esp
> 0xbfb34fc8	0xbfb34fc8 ebp            0xbfb350dc	0xbfb350dc esi
> 0x1f4	500 edi            0x12cf0f8	19722488 eip            0x222ca3
> 0x222ca3 <__tzfile_read+83> eflags         0x200202	[ IF ID ] cs
> 0x73	115 ss             0x7b	123 ds             0x7b	123 es
> 0x7b	123 fs             0x0	0 gs             0x33	51 (gdb) x/i
> $eip => 0x222ca3 <__tzfile_read+83>:	movl   $0x0,0x9c0(%ebx) (gdb)
> i r ebx ebx            0x319ff4	3252212 (gdb) x/x $ebx+0x9c0 
> 0x31a9b4 <transitions>:	0x012ce928 (gdb) x/i $eip => 0x222ca3
> <__tzfile_read+83>:	movl   $0x0,0x9c0(%ebx) (gdb) 0x222cad
> <__tzfile_read+93>:	lea    -0xc(%ebp),%esp (gdb) 0x222cb0
> <__tzfile_read+96>:	pop    %ebx (gdb) 0x222cb1 <__tzfile_read+97>:
> pop    %esi (gdb) 0x222cb2 <__tzfile_read+98>:	pop    %edi (gdb) 
> 0x222cb3 <__tzfile_read+99>:	pop    %ebp (gdb) 0x222cb4
> <__tzfile_read+100>:	ret (gdb)
> 
> As I mentioned, this is detected by glibc when freeing our
> controlled chunk (i.e. transitions), before returning from
> __tzfile_read. In the video, I see you used dividead's exploit
> without change, thus malloc(0) most likely allocated from fast
> bins, and you probably had the __tzfile_read (i.e. f) file
> structure allocated nearby within the ~50000 adjacent bytes, and
> had this corrupted at some place in main arena (since file
> structures are larger than 64 bytes and will not be allocated from
> fast bins). You probably will see this behaviour repeat, but most
> likely the file structure will not be located at the same offset in
> your buffer.
> 
> For SELinux, unfortunately it seems that with the appropriate
> configuration of "allow_ftpd_full_access" disabled and
> "ftp_home_dir" enabled, a vsftpd process chrooted and confined
> (i.e. ftpd_t) allow locale files to be opened not having the
> locale_t type (i.e. user_home_t, in this case), which if don't
> allow would have completely mitigated this issue. Dan, could you
> fix this in SELinux policy?
> 
> Thanks,
> 
Ramon, not sure I understand, what are you trying to prevent here?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7mLiUACgkQrlYvE4MpobNtwgCfZ5sbCzTua49wu3DOXklNZdQe
JVYAoMgpYq4fXoqQj5kVig9oyTzU8uP6
=LTnJ
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/