Friday, May 29, 2009

vsftpd-2.1.2 released and new security tricks

(Note: v2.1.2 is the same as v2.1.1 but with a compile fix)

vsftpd-2.1.2 is released with full details as always on the vsftpd home page:

http://vsftpd.beasts.org/

For users, a couple of nasty regressions are fixed: SSL transfers would drop due to an errant timeout firing; this is now fixed. Also, an absent per-user config file was fine with v2.0.7 but an error in v2.1.0. v2.1.2 restores v2.0.7 behaviour.

For Linux developers / security types, there are a couple of much more interesting stories:
  • RLIMIT_NPROC support. Least interestingly, the unprivileged vsftpd processes limit their own ability to launch new processes. A compromise of such a process now does not get to cause a nuisance by flooding the system with more processes. In addition, privilege escalations via kernel bugs in the copious clone() API and involving subtle interactions between collaborating evil processes should be mitigated.

  • RLIMIT_NOFILE support for some of the unprivileged vsftpd processes. This excellent defensive tweak comes courtesy of my colleague Tavis Ormandy with further research by Julien Tinnes. When set to 0, this limit prevents a process from gaining any new file descriptors. So a compromised unprivileged process doesn't get to create new network sockets or open new files. Of course the filesystem aspect is not as good as chroot() because non-fd-based syscalls such as stat() etc. will still leak information and something like rename() may present a total compromise. So there's limited value without combination with a chroot() and also a switch to a different UID to prevent devastating ptrace() attacks. This is a shame because this facility is available to non-root users; and options to voluntarily jail yourself as a non-root user under Linux are generally terrible. There are a couple of additional annoyances: POSIX requires that RLIMIT_NOFILE==0 prevents any file descriptors in a poll() call but curiously not select(). Also, the limit includes file descriptors passed in over a UNIX socket so this precludes some neat designs. Still, an interesting tweak to bear in mind.

  • CLONE_NEWPID / CLONE_NEWIPC support for all distinct vsftpd sessions. These flags were added to the Linux kernel extremely recently, and essentially allow you to launch new processes in isolated PID and IPC ID spaces. This represents further limits on the damage that a compromised vsftpd process could cause. The isolated PID space means no ability to kill() all other vsftpd sessions. (Note that the more serious ptrace() is already carefully defended against with management of the per-process "dumpable" concept). The isolated IPC ID space means no ability to abuse the common flaw of IPC objects with inappropriate world-access permissions.

7 comments:

Anonymous said...

Seems to have a problem with openssl (0.9.8k) while compiling:
http://nopaste.info/c0d9de9841.html

NickL said...

Trying to compile vsftpd-2.1.2 on an AIX 5.3 (TL09) system but it fails at:
sysutil.c: In function 'vsf_sysutil_set_no_procs':
sysutil.c:2786: error: 'RLIMIT_NPROC' undeclared (first use in this function)
sysutil.c:2786: error: (Each undeclared identifier is reported only once
sysutil.c:2786: error: for each function it appears in.)
make: The error code from the last command is 1.

Can anyone help? Thank you

Anonymous said...

we've same problem compiling on Solaris 10 (SPARC). We've modify vsf_sysutil_set_no_proc

void
vsf_sysutil_set_no_procs()
{
int ret;
struct rlimit rlim;
rlim.rlim_cur = 0;
rlim.rlim_max = 0;

#ifdef RLIMIT_NPROC
ret = setrlimit(RLIMIT_NPROC, &rlim);
#else
rlim.rlim_cur = rlim.rlim_max = RLIM_INFINITY;
ret = 0;
#endif
if (ret != 0)
{
die("setrlimit NPROC");
}
}

doink said...

I installed 2.1.2 on a Mac OS x 10.4 box, upgraded from a 2.0.7 installation.

It runs, but for some reason PAM isn't working - I keep getting auth errors for known good users. I kept the existing vsftpd.conf and pam.d files from the previous install, so I'm not sure what the problem is -- did something change PAM-wise?

Anonymous said...

With
LFTP | Version 3.7.14
VSFTPD v2.1.2
(which are both the very latest versions IMHO)
i still get:

# lftp -u user,pass host.dyndns.org
lftp user@host.dyndns.org:~> ls
ls: Access failed: 522 SSL connection failed; session reuse required: see require_ssl_reuse option in vsftpd.conf man page

Wasn't this supposed to work fine by now?

Chris Evans said...

@Anonymous: works with my lftp, v3.7.8-1 as part of Ubuntu 9.04. I still don't know what makes one version work and another not work. How was your lftp built, and what version of which crypto library is it linked against?
As always, the require_ssl_reuse option can get around this for you.

crisis said...

vsftpd doesn't work at all with run_as_launching_user=YES
Added more info to:
http://pastebin.com/m74b93bc0

I also found some other problems and I couldn't find a good place to post them. Where should one post vsftpd bugs?