UXSS Day One Wrapup

Well, it's been out there for over 24 hours now (more, if you count the original announcement at 23C3). Here's a handy wrap-up all in one place of what we know about it:

• There are actually several "features" in Acrobat that allow functionality to be injected as anchor code in a URL.
• It was called PDF Javascript injection, but because it's new it has to have a name, so it was dubbed (quickly) UXSS - Universal XSS.
  
• One flaw as a result of these features is that anchors (arbitrary ones, in addition to page, zoom, search, XML, etc.) allow javascript to be injected.
• This particular vulnerability requires Acrobat Reader, and a version prior to 8.
• Attacks against this work on Windows easily because Acrobat is the de-facto standard plugin for PDF's. Works in IE, Firefox, and Opera. There should be very little Mac or Linux impact because the default PDF readers on those platforms are built-ins.
  
• The Javascript is executed by the browser not by Acrobat.
• Because the script is part of an anchor, and the browser doesn't send anchor as part of the request, server-side logs will not show a difference in a legitimate request vs. a hacked one.
• This seems to work in all browsers such that Acrobat is used as a plugin, and that it's configured to show PDF's in the browser.
• Clients can protect themselves by de-selecting Open PDF's in Browser Window in Acrobat Preferences - or use 8 or newer - or use a different plugin for viewing PDF's.
• On the server side, there are several fixes: using "lContent-disposition: attachment" for all PDF's, forcing requests for PDF's through an additional 30x response to "purify" the URL bar, or using a bit tunnel with a transaction token.
• The impact of this is huge. There are basically no sites that have naked PDF's for download that aren't susceptible.
• This vulnerability is just like any other unauthenticated, reflected XSS attack - usable for lots of stuff by tricking a victim user into clicking a link. The usual suspects are session fixation and/or phishing by DOM scripting or simple redirecting.
• Because the browser is executing the javascript, the usual client javascript controls are in place - no cross-domain XHR, no cross-domain IFRAME reading, etc.
• This is really, really, really, really big.
• This is the first of many, many of these types of client-side plugin vulnerabilities we're going to see.

I'm not trying to steal any thunder here - just thought I'd wrap up everything in one post. Be sure to see the link above, RSnake's blog, and WASC (particularly the mailing list).

A better solution to the UXSS problem

There's a far more elegant server-side solution to the UXSS PDF problem on RSnake's site. mbrisby says to just add a Content-disposition header to force the document to an attachment. Content-disposition is a MIME directive that can include lots of information about how the user agent is supposed to deal with the content. In HTTP, you can direct the browser to do a Save As dialog, rather than displaying the content inline.

In Apache, this can be done quite easily. In your main config file for apache, outside of any Directory or VHost directives, add something like the following:

<FilesMatch "\.pdf$">
Header append Content-disposition 'Attachment'
</FilesMatch>

I've tried to find similar functionality in IIS but haven't found anything yet. Not sure about other server configurations.

Kudos to mbrisby for giving a far simpler solution.

UXSS - a really good thing

When these type of vulnerabilities come up, they're generally really rotten. But I think this one's actually a good thing - because the (developer-side) fix for the vulnerability is the same as the fix for XSRF - authenticating where the request came from prior to here with a transaction token.

UXSS will get a lot more media attention and get a lot more people fixing problems than XSRF has to date. Except XSRF, while harder to exploit, is probably as bad of a problem. It's just that we've not taken XSRF very seriously. Once we have a good server-side fix for this, we've got the right fix for XSRF - so this may be a means to fixing another problem.

Developers, please fix the UXSS vulnerabilities by using a bit tunnel. And then apply the same tools to fix all your XSRF.

Protecting your Customers from UXSS

Well, it already has a name - UXSS. One of the vulnerabilities uncovered at 23C3 - arbitrary XSS from PDF's. Universal Cross-site Scripting. And so it begins - another race to name a vulnerability.

But I digress. You can actually protect yourself here, without taking PDF's off your site. But it's not easy. It will take engineering and time.

You need to apply a level of indirection. In this case, your PDF's need to go into a non-web-accessible directory. Then you need to use a bit tunnel to transmit the PDF. Everybody's seen these before, and most of you have written them and use them elsewhere on your site. In simple terms, it just opens up a non-accessible file and transmits the bits.

With these, you need to make sure that the bit tunnel has a whitelist of what files it can open so that you don't allow directory traversal or arbitrary file download by altering the parameter. And you also need to apply transaction tokens here. Make sure to at least check the referrer, but preferably use a hidden form element with a token that is also in the session. The bit tunnel needs to check this transaction tunnel to ensure that the user got here from somewhere you know about.

So there's the fix. It's not easy, and it will take a couple of hours, unless you already use all those controls (bit tunnel, with a token check, and with a whitelist). It also makes it a bear to update your site. But your customers are worth the trouble, aren't they?

MOAB and More!

I think the first boog found in the Month of Apple Bugs is probably going to be indicative of the types of attacks that we'll see many, many, many more of. Obviously the RTSP boog in Quicktime isn't the first, but one of the more recent. There was the Quicktime scripting boog that was all the rage on MySpace. Now there's the buzz about cross-domain scripting in PDF's. (PDF's for cryin' out loud! I thought PDF was Portable Document Format - not applicaction!)

And there's the fact that JPEG's can carry arbitrary payload....

I think these are the types of bugs we're going to see more and more of over the next several months. I'm sure other very popular media player plugins will have flaws, which will make Google and YouTube look bad.

And sadly, right now, there's not much we as developers can do about it. Do we tell users to disable the features? Do we remove those types of media from the site? Do we just cross our fingers and hope for patches, and quicklike?