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