Re: vsFTPd remote code execution

[Chris Evans <scarybeasts () gmail com>]

On Sat, Dec 17, 2011 at 9:44 PM, Chris Evans <scarybeasts () gmail com> wrote:
> On Thu, Dec 15, 2011 at 5:39 AM, 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 /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 () 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/