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

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

Powered by blists - more mailing lists