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).