Full Disclosure mailing list archives
Re: vsFTPd remote code execution
From: xD 0x41 <secn3t () gmail com>
Date: Fri, 16 Dec 2011 06:03:35 +1100
There is guides, like; http://blog.up-link.ro/how-to-set-up-vsftpd-virtual-users-berkeley-db-pam/ wich is folwing this trend...to create a var/ftp/public or var/ftp/user , wich is great...if your not running vsftpd... On 16 December 2011 00:39, HI-TECH . <isowarez.isowarez.isowarez () googlemail com> wrote:
Hi Chris, Am 14. Dezember 2011 08:21 schrieb Chris Evans <scarybeasts () gmail com>:On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH . <isowarez.isowarez.isowarez () googlemail com> wrote:Yes you are somewhat right, as this is the old discussion about if code execution inside an ftpd is a vulnerability itself or only local code execution. I have the opinion that an ftpd which does not allow to run code should restrict the user so, and if there is a way to execute code it it is a vulnerability. Take the example of a vsftpd configured for anonymous ftp and write access in /var/ftp.IIRC, vsftpd can refuse to start an anonymous session for the misconfiguration where the root directory is writeable (to avoid problems in the libc like this). I'll make sure it still works and maybe check other paths such as /etcthats indeed true, nevertheless I have seen boxes in the wild with vsftpd running with anonymous and write access in /var/ftp, maybe because this security measure was built into vsftpd in newer versions ? I am not sure.For local users, there's a configuration setting: "chroot_local_user". The compiled-in default is false, and the man page cautions: --- .BR Warning: This option has security implications, especially if the users have upload permission, or shell access. Only enable if you know what you are doing. --- I'm not uptodate with whether Linux distributions have turned this on by default or not.I think it is not the default setting but many admins will make use of it in hosting environments.vsftpd does have the concept of "virtual users". I'm not sure if it's widely used but it seems that this type of user login would present the biggest headache. Amusingly, vsftpd already attempts to desist glibc from loading any timezone files from inside the chroot() (see env_init) by warming up the subsystem and even explicitly setting TZ in the environment. glibc displeases me. Perhaps it's a gmtime() vs. localtime() issue -- I'm curious to know if glibc still crashes if the setting "use_localtime=YES" is used?I havent checked that but as you said in a private conversation cacheing the zoneinfo file through glibc beforehand makes the zoneinfo file usage disappear in my strace output.I don't mind adding workarounds or avoidances for libc bugs (for example, functions like regcomp, fnmatch have long been avoided). If you had any clever ideas, I'm happy to put them in, otherwise it's a case of waiting for the glibc updates.For me it is a miracle why this bug was not patched in glibc back in 2009. Here is the patch by you Chris I hope I can go ahead and post it here on full disclosure as this might get into a new release anyways (use at your own risk!): Add this to the very bottom of vsf_sysutil_tzset(): ---snip--- p_tm = localtime(&the_time); if (p_tm == NULL) { die("localtime #2"); } p_tm = gmtime(&the_time); if (p_tm == NULL) { die("gmtime"); } ---snip--- Regards, KingcopeCheers ChrisThe attacker might execute code using the vulnerability without authentication credentials, or for example an attacker only has access to a user account configured for ftp. Basically you are right, vsftpd uses privsep so its a not so risky vulnerability. /Kingcope Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg <dan.j.rosenberg () gmail com>:Anyone with an up2date linux local root which only makes use of syscalls? :>This is all fun stuff, and definitely worth looking into further, but if you've got a local kernel exploit that you can trigger from inside vsftpd, you don't need this (potential) vulnerability in vsftpd - you already win. -Dan_______________________________________________ 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 - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________ 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 code execution HI-TECH . (Dec 13)
- Re: vsFTPd remote code execution Dan Rosenberg (Dec 13)
- Re: vsFTPd remote code execution HI-TECH . (Dec 13)
- Re: vsFTPd remote code execution Dan Rosenberg (Dec 13)
- Re: vsFTPd remote code execution HI-TECH . (Dec 13)
- Re: vsFTPd remote code execution Chris Evans (Dec 13)
- Re: vsFTPd remote code execution HI-TECH . (Dec 15)
- Re: vsFTPd remote code execution xD 0x41 (Dec 15)
- Re: vsFTPd remote code execution Chris Evans (Dec 17)
- Re: vsFTPd remote code execution HI-TECH . (Dec 13)
- Re: vsFTPd remote code execution Dan Rosenberg (Dec 13)
- Re: vsFTPd remote code execution HI-TECH . (Dec 13)