Clusterfuzzing

I've just noticed that a Google search for "clusterfuzzing" (including the quotes) has no hits. Therefore, I'm reserving the term :) All I need now is a new fuzzing angle and then I've got all the makings of a great presentation!

Actually, I do have a new twist on fuzzing. All I need is the bugs. Watch this space!

Bonus Safari XXE (only affecting Safari 4 Beta)

Here's another XXE bug for you (resulting in file theft), just to make the point that this class of bugs is well worth watching out for in client-side applications (such as a browser :)

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

The good news here is that this WebKit regression was quickly fixed by Apple -- and in time for the Safari 4 final release -- so no production browser should ever have been affected. Just the Safari 4 Beta.

Full credit here to Carlos Pizano who noticed the WebKit regression due to a collision with the Chrome sandbox. I just put together the Safari test case / demo:

https://cevans-app.appspot.com/static/safari4filetheft.xml

Apple's Safari 4 also fixes cross-domain XML theft

Safari 4 also fixes an interesting cross-domain XML theft. Full technical details live here:

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

XML theft can include highly sensitive data thanks to things like XHTML, AJAX-y RPCs using XML and authenticated RSS feeds. The example I have steals XML representing a logged-in Gmail user's inbox:

Safari 3 demo for users logged in to Gmail

I think there's a lot more room for browser-based cross-domain leaks (sometimes called UXSS or universal XSS). This is because the pace of new browser features is very high, and lots more functionality is being added that involves reference by URI. Every such addition is a possible vector for a missing or incorrect (e.g. 302 redirect tricks) cross-domain check; or even an ill-advised specification-based cross-domain leak.

This is one of the serious Safari bugs demoed but not disclosed at my PacSec and HiTB Dubai presentations. I forgot to note that my previous post on file theft was another.

Apple's Safari 4 fixes local file theft attack

Safari 4 was just released and among the various improvements is a range of security fixes. One of these fixes is for an XXE attack against the parsing of the XSL XML. Full technical details may be found here:

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

Or for the lazy, you can skip straight to the:

Demo for Safari 3 / MacOS
Demo for Safari 3 / Windows

I found it interesting that Safari 3 seemed robust against XXE attacks in general -- there are a lot of places that browsers find themselves parsing XML (XmlHttpRequest, prettifying XML mime type documents, SVG, E4X, etc.) However, the relatively obscure area of the XSL XML succumbed to an XXE attack.

(Note: awareness of XXE attacks remains low despite the issue being documented since at least 2002).

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.

A more plausible E4X attack

As a quick recap, "E4X" is the name of a Javascript standard relating to strong XML support in the language. Firefox has had an implementation for quite some time but no other major browser seems to have followed suit.

My colleages Filipe Almeida and Michal Zalewski led the way in E4X security; check out:

http://code.google.com/p/doctype/wiki/ArticleE4XSecurity

However, the attack scenarios in that document are in my opinion not likely to occur in many web apps. It so happens that I was fiddling around the night before my HiTB talk (which briefly covers E4X) and I came up with something more compelling. Take a hypothetical web mail service which provides an XML feed format of the inbox, which might look something like this:

<inbox>
<mail id="1234"><from>evil@hacker.com</from><subject>{ x = '</subject><body>PWN...</body></mail>
<mail id="1235"><from>bank@bank.com</from><subject>Super sensitive!</subject><body>New pin: 9976</body></mail>
<mail id="1236"><subject>' }</subject><body>...ed!!</body></mail>
</inbox>

One general concept of interest in the above fragment is the ability of the attacker to echo little pieces of attacker-controlled text onto a trusted domain. Specifically, in e-mail subject text! More on this in another post.
With this realization, we're all set to mount an E4X-based theft attack. First, you'll want to see it in action. You'll need Firefox to see the popup alert indicating cross-domain XML theft:

https://cevans-app.appspot.com/static/e4xtheft.html

The attack works by cross-domain including the XML formatted inbox into the attacker's page via <script src="blah">. Raw XML is valid Javascript in Firefox, thanks to E4X, so this parses and executes in the attacker's context. The reason the attacker is able to mount a theft is that E4X looks for curly braces in XML values and tries to interpret the surrounded text as a Javascript expression to evaluate. Looking again at our above XML, we see the following in the middle:

<subject>{ x = '</subject><body>PWN...</body></mail>
<mail id="1235"><from>bank@bank.com</from><subject>Super sensitive!</subject><body>New pin: 9976</body></mail>
<mail id="1236"><subject>' }</subject>

As you can see, the attacker's sneaky choice of subject lines has caused an expression to be evaluated which:

• Wraps a part of the XML in single quotes, forming a Javascript string literal.
• Assigns said string literal to a Javascript variable in the attacker's domain!
• Leaves the XML tag structure balanced, thanks to the repeating nature of the XML tree.

For the attack to work, there are constraints:

• There must be no newlines in the part of the XML structure that you are stealing, because Javascript literals cannot span unescaped newlines.
• There must be no XML prolog or DTD since these break the Firefox E4X parser.
• The single quote character must be rendered into XML values unescaped and double quotes must be used to surround XML attributes (or visa versa).

There will be real-world services matching these constraints. When you find them, drop me an e-mail or leave a comment.
As always, Mozilla security responded wonderfully to this advance in E4X theft. A behavioural tweak was committed and is due in Firefox 3.5, which will break this attack.

HiTB Dubai: all over apart from the blogging

I recently had the pleasure to be invited by Dhillon to present at HackInTheBox (HiTB) Dubai with Billy Rios on our "Cross Domain Leakiness" work. Here is a link to our updated slides:

http://docs.google.com/Presentation?id=dfgb2455_72fkwc2phc

It was a very productive conference, all told. The sort of conference where new attacks materialise over breakfast conversations. In terms of new and pending material, I'll do separate posts regarding:

• My latest E4X cross-domain theft attack (building on the work of my colleagues Filipe and Michal)


• A new "divided login" attack (Billy and I having fun over breakfast)


• JDK GIFAR fix considered incomplete


• A new cross-browser cross-domain theft

There was also a very interesting (and perhaps overdue) theme running throughout the conference. It was best put in words during Mark Curphey's keynote address: "builders vs. breakers". And my summary of this is that the industry has too many breakers and not enough builders. Builders have the maturity to step back from the world of random bugs and glitzy hacks, and move the state of security forward. But the economics of the security industry often selects for breakers: the 17 year old kid who finds an XSS in Twitter gets all the press attention; conferences are full of talks about one-off hacks and breaking technologies because the "let's fix it" talks are not showy enough; opinionated and technically lacking blogs and advisories seem to be favoured sources of information.

I'm going to be thinking about contributing more to the building side.