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,
