It is experimental and therefore off by default. It only currently supports i386 Linux (but there's no reason you couldn't hack the Makefile to build 32-bit on 64-bit Linux). When enabled, it only engages when using
one_process_model, i.e. simple anonymous-only configurations. To (try and) enable it, set
sandbox=YESin your config file. If you do try, please e-mail or leave a comment, even if it works!
But was it worth the effort? That's a very astute question; vsftpd already pioneered privsep support as a way of limiting the damage of a compromise of the FTP parsing code (or more likely OpenSSL, if enabled).
Let's briefly examine the damage that can be done in the event of a compromise of the low-privileged end of a privsep-based solution. Let's also assume the low-privileged end is running in a suitable
chroot()jail with no sensitive, writeable or setuid files. With arbitrary code execution, the attacker can still:
- Mount attacks against the kernel API to gain root
- Connect to internal RFC1918 networks, i.e. firewall bypass
- Connect to localhost, i.e. attack local-only services
- Cause a nuisance by spraying
- Mess with any shared objects (e.g. POSIX shared memory) with inappropriate permissions
- Subvert other processes with the same UID / GID via
ptrace()(vsftpd defends against this as long as you set
nopriv_userto a value unique to vsftpd)
- Abuse your CPU / bandwidth
If memory serves, historically there have been a number of attacks against ptrace() monitoring --- TOCTOU with shared memory used as arguments to system calls (something other than the stopped process has to be twiddling that memory) is the one I recall.
Great comment, Kragen. vsftpd avoids the TOCTOU race by not being multithreaded, and not sharing any writable mappings with other vsftpd processes. In addition, the sandbox policy is careful to not permit any shared writable mappings to be created. Signals are also a real problem in this area, so the policy does not permit signal sending either.
Post a Comment