Re: [Full-disclosure] VSFTPD Remote Heap Overrun (low severity)
> Hi Ramon, > Frankly I didn't look into the possibility to exploit this > vulnerability, > so i do not know if it is easy or hard to exploit. As you outlined > it is difficult, during your audit you did not manage to trigger a > function pointer call? :> i guess not I have not tried much, but I have not get ouside of glibc scope after the overflow within a controllable environment. In your video, It seems you overwrite the file structure used in __tzfile_read. Is this a constant and controllable behaviour? > I am not much into exploiting heap based overruns in the old times > fashion. > BTW both freebsd and pure-ftpd load locale files (strace it and you > will see) from /usr, > these locale files are used for the ftp responses to make them > written > in international language. > FreeBSD ftpd in junction with the locale files loading will SIGSEGV > (EIP overwrite) > due to a strcpy in locale responses in a special codepath. I did not > find a way to exploit Pure-FTPD through this > locale loading tough, because Pure-FTPD is very restrictive in many > ways even I have not looked this yet, I'll take a look as soon as I have some time. But thanks for the additional information. > on response lines but there might be a vuln there too. (I dont > remember if locale loading was only > on FreeBSD or also on Linux or also in vsftpd, since the libc behaves > very different in BSD/glibc/eglibc etc) One important thing to note is in Fedora and RHEL, when running SELinux, vsftpd runs confined by default, and can be configured by the following booleans: [rcvalle@localhost ~]$ getsebool -a | grep ftpd allow_ftpd_anon_write --> off allow_ftpd_full_access --> off allow_ftpd_use_cifs --> off allow_ftpd_use_nfs --> off ftpd_connect_db --> off [...] [rcvalle@localhost ~]$ And unless the boolean allow_ftpd_full_access is enabled, vsftpd may not be allowed to read this file by default. Could you cause this running the vsftpd installed from packages distributed with CentOS, Fedora, or RHEL? I'm copying Dan Walsh so he can comment on this. > > Regards, Thanks for forwarding my message to the list. It seems that my Red Hat email address has not yet been approved. John, can you approve this email address please? -- 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/
Re: [Full-disclosure] VSFTPD Remote Heap Overrun (low severity)
> This is afaik a patched CVE in Linux glibc [1] which can be triggered through > the very secure ftp daemon [2] so it will only work on older linux distros. > Be aware that vsftpd has privilege seperation built in so this bug > will not yield a root shell. > It could yield root only in junction with a linux kernel vulnerability > because the attacker > will not be able to break the chroot without being root. > This bug has a low severity because it's hard to exploit. > Linux systems without patched glibc are vulnerable even if the latest > version vsftpd-2.3.4 is installed. > The bug is in the glibc timezone code. vsftpd loads timezone files > from /usr [3]. If the attacker is inside a chroot > he can easily create this directory and the timezone file and trigger > the heap overrun. > > A Debugging Session illustrating the bug can be found on youtube: > http://www.youtube.com/watch?v=KRCuozBM_dQ I did a brief analysis of this issue. And it seems vsftpd does not add anything to this as an attack vector. Althought we can control the size of the chunk to be allocated (i.e. transitions), and can arbitrarily allocate this chunk from fast bins, the main arena, or eventually, a new mmap()'ed heap. We do not have any control over when its adjacent chunks are allocated, freed, the type of their contents, when they will be used, how they will be used, and if they will be used and useful at all. In addition, the data used to overflow (i.e. transition times) are read and decoded as 4-byte integers in network (big-endian) byte order, which increases the difficulty in faking any structure, such as the adjacent allocated chunk to, at least, get outside of glibc scope after the overflow--since all return paths from __tzfile_read frees our controlled previously allocated chunk. Do you or anyone know a way to potentially exploit this vulnerability? > > Cheers! Thanks, > >[1] http://dividead.wordpress.com/tag/heap-overflow/ >[2] https://security.appspot.com/vsftpd.html >[3] For example /usr/share/zoneinfo/UTC-01:00 > >/Kingcope -- 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/
[Full-disclosure] VSFTPD Remote Heap Overrun (low severity)
This is afaik a patched CVE in Linux glibc [1] which can be triggered through the very secure ftp daemon [2] so it will only work on older linux distros. Be aware that vsftpd has privilege seperation built in so this bug will not yield a root shell. It could yield root only in junction with a linux kernel vulnerability because the attacker will not be able to break the chroot without being root. This bug has a low severity because it's hard to exploit. Linux systems without patched glibc are vulnerable even if the latest version vsftpd-2.3.4 is installed. The bug is in the glibc timezone code. vsftpd loads timezone files from /usr [3]. If the attacker is inside a chroot he can easily create this directory and the timezone file and trigger the heap overrun. A Debugging Session illustrating the bug can be found on youtube: http://www.youtube.com/watch?v=KRCuozBM_dQ Cheers! [1] http://dividead.wordpress.com/tag/heap-overflow/ [2] https://security.appspot.com/vsftpd.html [3] For example /usr/share/zoneinfo/UTC-01:00 /Kingcope ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
