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.
  

Bypassing syscall filtering technologies on Linux x86_64

For those interested in syscall filtering technologies, check out my latest advisory on how policies can be bypassed under certain circumstances:

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

There's a neat trick on the x86_64 kernel; this kernel supports both 32-bit and 64-bit processes, and interestingly, the syscall tables are different in either case. However, with a bit of trickery, a 64-bit process can call a 32-bit syscall (and visa versa), and confuse the syscall filter.

This was discovered whilst experimenting on a new security feature for vsftpd; a future post will go into this.

Opera, SVGs and Java applets

Opera 9.63 was just released with some security fixes. I reported one of these issues, but neither myself nor Tarquin (a super friendly and knowledgeable Opera security guy) could do anything significant with it, despite feeling uneasy about the feature.

The issue is this: when an SVG image is included via an <img> tag, it is standard practice to disable running of JavaScript in that context. However, I noted that you could run a Java applet (and Flash presumably) in this context via the SVG tags such as <html:applet>.

A demo is here: https://cevans-app.appspot.com/static/svgapplet.html

Every attack we came up with is catered for. We discussed some very in-depth attacks (which I don't want to go into just yet) but Opera has some nice tweaks such as respecting Content-Disposition: attachment for SVG images referred to via the <img> tag. The Opera guys even checked that the unusual context of executing due to an <img> tag gets the domain correct (that of the img resource, not the hosting page). By the time I inquired about this, they had already checked.

I continue to be impressed with Opera; the bug was fixed lightning fast even though no severe impact is known. And a few little Opera defensive measures turned out useful. This follows on from Opera being immune to my image theft via SVG attack.

Not many browsers support this advanced feature. Aside from Opera, both Safari and Chrome support this. But they do not render Java applets in SVGs in the <img> tag context.

If you can think of a scenario where these embedded applets could cause more trouble that I've realized, please leave a comment or mail me :)

Firefox cross-domain text theft....

... and a reappearance of the "302 redirect trick".

Here's the second bug from my PacSec presentation, and it's another Firefox one; kudos to the Firefox security team for their responsiveness. It's fixed in the recent 2.0.0.19 and 3.0.5 releases.

It involves, yes, a cross-domain <script src="blah"> tag. These remain a horrible wart in web app security; you have to make sure that any authenticated resource on your domain either does not have any side effects when parsed / executed as JavaScript, or is CSRF protected.

This particular bug involves Firefox's window.onerror handler, which reports on JavaScript parse and execution errors. This handler has previously been used by Jeremiah Grossman to determine login status via script errors, see here! (Whereas this hole can be closed, it's not clear my similar attack via CSS can be).

The new attack notes that certain JavaScript error messages leak real content from remote domains, for certain constructs of data. More in-depth technical detail is here:

http://scary.beasts.org/security/CESA-2008-011.html

One cute twist is that Firefox 3 already had this fixed (thanks to Filipe Almeida; see credit below), but the "302 redirect trick" bypassed that fix. This trick is becoming quite fruitful; see previous Firefox image theft bug.

Credit to Filipe Almeida for being awesome. He was playing with this stuff long before anyone else.