Date: Thu, 15 Dec 2011 14:39:05 +0100
From: "HI-TECH ." <isowarez.isowarez.isowarez@...glemail.com>
To: Chris Evans <scarybeasts@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: vsFTPd remote code execution

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.

> 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 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.

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!):

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