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: <CAMnK33W75ti6PWw=ZszkyjZqrmXWvyC+C=cjsTFZgYZAHM0Kbg@mail.gmail.com> Date: Wed, 4 Jan 2012 12:21:05 -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 Sat, Dec 17, 2011 at 9:44 PM, Chris Evans <scarybeasts@...il.com> wrote: > 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 :) Hehe! I just noticed that FreeBSD was not so lucky: http://security.freebsd.org/advisories/FreeBSD-SA-11:07.chroot.asc Cheers Chris > > 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