Full Disclosure mailing list archives
Fwd: VSFTPD Remote Heap Overrun (low severity)
From: "HI-TECH ." <isowarez.isowarez.isowarez () googlemail com>
Date: Mon, 12 Dec 2011 13:09:58 +0100
Hi Ramon,
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 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.
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.
The youtube video shows a CentOS 5.5 default install with vsftpd compiled from sources as far as I remember, I didnt look into the SELinux conf tough. Sorry for the vague information but currently I am a bit busy, when I will find time I might clarify on these things. Regards, /Kingcope ---------- Weitergeleitete Nachricht ---------- Von: Ramon de C Valle <rcvalle () redhat com> Datum: 11. Dezember 2011 16:41 Betreff: Re: [Full-disclosure] VSFTPD Remote Heap Overrun (low severity) An: "HI-TECH ." <isowarez.isowarez.isowarez () googlemail com>, dwalsh () redhat com, johnc () grok org Cc: full-disclosure () lists grok org uk
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/
Current thread:
- VSFTPD Remote Heap Overrun (low severity) HI-TECH . (Dec 02)
- <Possible follow-ups>
- Re: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Message not available
- Fwd: VSFTPD Remote Heap Overrun (low severity) HI-TECH . (Dec 09)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) GloW - XD (Dec 09)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) GloW - XD (Dec 09)
- Message not available
- Re: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Fwd: VSFTPD Remote Heap Overrun (low severity) HI-TECH . (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Daniel J Walsh (Dec 13)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Daniel J Walsh (Dec 13)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Valdis . Kletnieks (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) lists (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Valdis . Kletnieks (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Fwd: VSFTPD Remote Heap Overrun (low severity) HI-TECH . (Dec 12)