Re: [Full-disclosure] vsFTPd remote code execution

On Thu, Dec 15, 2011 at 5:39 AM, HI-TECH .
<isowarez.isowarez.isowarez@xxxxxxxxxxxxxx> wrote:
Hi Chris,

Am 14. Dezember 2011 08:21 schrieb Chris Evans <scarybeasts@xxxxxxxxx>:
On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH .
<isowarez.isowarez.isowarez@xxxxxxxxxxxxxx> 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.


Add this to the very bottom of vsf_sysutil_tzset():

 p_tm = localtime(&the_time);
 if (p_tm == NULL)
  die("localtime #2");
 p_tm = gmtime(&the_time);
 if (p_tm == NULL)




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


Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg <dan.j.rosenberg@xxxxxxxxx>:
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.


Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -