lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAMnK33VO1M_0bsXOnhZ72uBhXAJEcVT3q8a0PqanQ+3Lit3+sg@mail.gmail.com> Date: Sat, 17 Dec 2011 21:44:15 -0800 From: Chris Evans <scarybeasts@...il.com> To: "HI-TECH ." <isowarez.isowarez.isowarez@...glemail.com> Cc: full-disclosure@...ts.grok.org.uk Subject: Re: vsFTPd remote code execution On Thu, Dec 15, 2011 at 5:39 AM, HI-TECH . <isowarez.isowarez.isowarez@...glemail.com> wrote: > Hi Chris, > > Am 14. Dezember 2011 08:21 schrieb Chris Evans <scarybeasts@...il.com>: >> On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH . >> <isowarez.isowarez.isowarez@...glemail.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 /etc >> > > thats 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. Weird. That's an awful config. Would you even need a glibc vuln to attack such an anonymous setup? I fiddled around with looking at how glibc loads /etc/nsswitch.conf (which can be used to provoke a shared library load from /usr/lib at runtime) and it looks like glibc caches /etc/nsswitch.conf across both fork() and chroot(), at least my version in F14. Nonetheless, there must be other interesting avenues of research along these lines :) For v2.3.5, I moved the check to be sure it's impossible to avoid it no matter how many options you fiddle with. > >> 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 also don't see any zoneinfo file loads in a default vsftpd config, FWIW. Seems to need use_localtime=YES => localtime(). Although one of the crash stacks pasted goes via gmtime() so YMMV and it may be glibc version dependent. >> >> 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. I think it's still not fixed but being actively worked on. I wonder if the /etc/passwd parser is robust :-P Any other system files you can think of that might end up getting parsed in the context of a typical FTP server? > > 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!): I just put it in a v2.3.5 release because it seems simple enough. Cheers Chris > > 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, > > Kingcope >> >> Cheers >> Chris >> >>> The 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@...il.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/
Powered by blists - more mailing lists