Re: [Full-disclosure] Fwd: VSFTPD Remote Heap Overrun (low severity)

[Ramon de C Valle <rcvalle@xxxxxxxxxx>]

> 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 de C Valle / Red Hat Security Response Team

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