-----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/
