What you need to know about the UXSS in the Acrobat Plugin

Update: Coverage by Dark Reading with yours truly quoted:

"This find changed Web app expert Jeremiah Grossman's mind about the bug. Yesterday, Grossman, CTO of White Hat Security, had said the PDF XSS bug didn't really raise the XSS risk level overall. But in light of RSnake's finding, Grossman now considers this "really bad" and worries that it could be used as a payload for attacks much worse than XSS."

To clarify I was thinking the issue didn't raise the risk level of XSS since just about every website is vulnerable anyway.

The industry is buzzing with chatter about the Universal XSS vulnerability in Adobe’s Acrobat Reader Plugin reported by Stefano Di Paola and Giorgio Fedon. The discovery is impressive, confusing, and scary on a number levels. If it was disclosed prior to January, it probably would have made our Top 10 Hacks of 2006. What a way to kick off the year.

Anyway, I’ve been reading the reports and the data conflicts all over place. InfoSec people are having the same problem. They’re unsure about what this is or what they need to do about it. I’ll try to boil this down to the relevant points and see if I can help out.

Here’s how the attack works:

1. Attacker locates a PDF file hosted on website.com
2. They create a specially crafted URL pointing to the PDF append with some JavaScript Malware in the fragment portion (Example: http://website.com/path/to/file.pdf#s=javascript:alert(”xss”);)
3. Attacker entices a victim to click on the link
4. If the victim has Adobe Acrobat Reader Plugin 7.0.x or less, confirmed in Firefox and Internet Explorer, the JavaScript Malware executes.
5. Everything XSS has shown to be capable of including Phishing w/ Superbait, Intranet Hacking, Web Worms, History Stealing, etc is now available to the attacker.

Things to keep in mind

1. The vulnerability is very pervasive as it lowers the hackabilty bar from the target website needing to have an XSS issue to simply hosting a PDF.
2. Normally XSS vulnerabilities are a problem in the server-side code, this one is on the client-side (web browser).
3. The fragment portion of the code, where they payload is stored, is NOT submitted to the web server. So the server can’t see it, and won’t be able to block it.
4. Several server-side work-arounds have been suggested, but caution is advised since these are all new and relatively untested. Though we might not have much choice.
5. Best advice is for users to patch, or re-configure, but that’ll take some time to roll out to the masses.

As bad as this is, it gets worse

RSnake wins the award for breaking the Web, again. He found that it’s possible to point the malicious URL to a default PDF file location on the local filesystem:

file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#blah=javascript:alert("XSS");

This means the JavaScript Malware now runs in local context with the ability to read local files and oh so much more! What more does a bad guy need!? Another amazing find.

Wake up browser vendors! It’s time to deal with this stuff!