Thursday, January 04, 2007

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
  2. They create a specially crafted URL pointing to the PDF append with some JavaScript Malware in the fragment portion (Example:”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:


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!


Anonymous said...

I tried it with:"xss");

And I don't see any alert box.

IE6 SP2, Adobe Reader 8.

When using IE6 SP2, Adobe Reader 5 shows the alert box.

Anonymous said...

Adobe's Official advisory:

Cengal said...

Web admins can do something to help.

If they host pdfs on a site and don't wish to be used as a basis to launch an attack, they could configure rewrite rules so any URL to a pdf gets redirected to the same url with the parameters trimmed from the end.

Anonymous said...

Hi Jeremiah, Good article.

I tryed a very different approach by forcing a use to download an .xpi FF extension file through e-mail by using UXSS in PDF.


I thought it would be fun to try it.


Anonymous said...

Ok I posted this at it is my last attempt (and I tons of methods, in vain) But the next thing seems to work for me.


AddType application/octet-stream .pdf
AddType application/octet-stream .PDF

And this worked for server PDF files, not only typed into the URL bar, but also as a link. It forces to download the PDF and shows no XSS.

At least on my server, I emptied cache a couple of times and test with and without .htaccess and it seems that it works.

Be sure to empty your cache on every reqeuest. Let me know if it works for you also, I really hope it is not some flaw on my server, I had many false positives with other methods, so you never know.


Anonymous said...


might be a bit off topic, but I also very much dislike that Adobe Reader has JavaScript capabilities. I recommend anyone to disable JavaScript in Adobe Reader.


Anonymous said...

This is very widespread vulnerability. I have already written my own article about UXSS (in Ukrainian).

And you may look at this example of such hole at microsoft's site :-).'XSS')

Jeremiah, not just Firefox and Internet Explorer, but also Mozilla which I use (Mozilla 1.7.7) have this issue. So this hole is in IE6 (and IE5 also), Mozilla, FF1 and FF2 and Opera on Windows XP (and potentially other Windows non-XP platforms), just need Acrobat plugin installed in your browser.

And it is really danger and widespread vulnerability. The are up to 317 000 000 sites over the Web which have pdf files (as Google said). And every admin of every site need to deal with this Universal XSS in PDF.