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