Linux kernel minor "seccomp" vulnerability

I just released some technical details on why and how "seccomp" is vulnerable to the Linux kernel syscall filtering problems that I previously blogged about. The full details may be found here:

http://scary.beasts.org/security/CESA-2009-004.html

The actual bug is of little significance because pretty much no-one uses seccomp:

This searches for the PR_SET_SECCOMP string on Google Code Search

In addition, even if people did use this -- the bug is not a full break out, just some leakage of filesystem names via stat() or mischief via unrestricted chmod().

However, I still find this vulnerability interesting. It's a sobering reminder that even a very simple security technology can have surprising bugs. seccomp applies extremely tight restrictions on untrusted code, but within these constraints, the code still has opportunities to misbehave! And this isn't the only example. For reference, check out how a seccomp-constrained process could historically cause trouble in the syscall tracing path with:

CVE-2007-4573: trouble with the upper 32-bits of %rax not clear

CVE-2008-1615: trouble calling syscalls with a bad value in the %cs register

CVE-2004-0001: trouble with EFLAGS, unknown trigger

Linux kernel minor signal vulnerability

I recently came up with a little API abuse of the clone() system call. Not earth shattering, but definitely fun. Essentially, you can send any signal you want at any time to your parent process, even if it is running with real and effective user id of someone else (e.g. root). Full technical details and an example may be found here:

http://scary.beasts.org/security/CESA-2009-002.html

Maybe someone more devious that me can come up with better abuse scenarios than I can. Have at it...

Signals are a tricky area of the kernel on a lot of levels. I find it interesting that every slightly unusual way to send signals in the kernel has suffered from access control issues in the past. For example, this COSEINC advisory notes issues in sending signals via prctl(PR_SET_PDEATHSIG, ...). There were multi-vendor issues with fcntl(..., F_SETOWN, ...) a long time ago which resurfaced in a Linux-specific manner a little after.

vsftpd-2.1.0 and ptrace() sandboxing

The new sandboxing support mentioned in the vsftpd-2.1.0 announcement post is actually a ptrace() based sandbox.

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=YES in 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 SIGKILL signals around
• 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_user to a value unique to vsftpd)
• Abuse your CPU / bandwidth

The sandbox eliminates most of the above concerns and drastically reduces the attack surface on others. On the downside, there are some minor performance losses such as an extra process per-session and per-syscall overhead but nothing severe. So for extreme paranoia, perhaps there is benefit here. We'll see.

vsftpd-2.1.0 released

I just released vsftpd-2.1.0, with full details being available on the vsftpd web page:

http://vsftpd.beasts.org/

It fixes a bunch of bugs and compile errors, introduces a few minor new features, has some code clean ups, etc. etc.

vsftpd-2.1.0 is interesting from a security perspective because of its changes to SSL support. It actual contains a reasonable resolution to the connection theft attack I blogged about here:

http://scarybeastsecurity.blogspot.com/2008/02/your-ftp-ssl-solution-is-really-secure.html

In the linked advisory I said "I have a crazy idea to use the SSL session cache as a cheezy form of authentication". Well, thanks to investigation by Tim Kosse of FileZilla fame, it turns out this is a very feasible option. Better still, a large number of clients already (whether they know it or not) use SSL session reuse between the control and data connection. This includes up to date versions of FileZilla, lftp and command line ftp-ssl. Therefore, vsftpd now defaults to requiring SSL session reuse. If your SSL FTP client does not re-use sessions, you can turn this off but you would do better to change FTP clients. Tim's FileZilla seems like a pretty awesome option to me. Hopefully other FTP servers will follow suit (quick source code scanning of popular open source ones seemed to lack a call to the relevant SSL_session_reused OpenSSL API.

Other new security features are:

• A per-process memory map limit of 100Mb. Just because it was easy, really. Note however!!! A memory leak in a session-private, isolated child process of a daemon cannot really be considered a security problem in this day and age -- unless you're on crack.
  


• An ambitious new built-in sandbox. Think of it as privsep++, but more on this in an upcoming post and paper.