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.