[Update, 1/6/07: Google has implemented a workaround for this vulnerability on their servers, so the proof-of-concept links in this posting will no longer demonstrate the exploit]

Cross-site scripting (XSS) just got a lot scarier. At the 23rd CCC, Stefano Di Paola and Giorgio Fedon announced a new attack vector which basically puts any site hosting a PDF file at risk for XSS. The attacker doesn't need to control the PDF, the mere existence of the PDF file on the server is enough. Here's a basic example (if an alert box pops up, you're vulnerable):


And of course the classic example of exploiting an XSS vulnerability involves leaking the contents of the victim's cookie, either by sending it to the attacker by concatenating it to an HTTP request, or, more recently, by using Ajax to issue a series more complex requests. Here's the same example displaying the cookie:

http://www.google.com/ads/techb2b_news.pdf#foo=javascript:alert('Your Google cookie:n' + document.cookie)

It goes without saying that a real attack would carry out its mischief without actually displaying pop-up dialogs to the victim.

This gets even more interesting if the targeted website has CSRF vulnerabilities. Remember the GMail Contact List CSRF vulnerability from a couple days ago? Now you wouldn't even need to trick the victim into loading your malicious web page (or clicking an XSS link on some other site) in order to exercise the CSRF attack. Even the security-conscious users who use Firefox plugins such as NoScript to selectively enable Javascript most likely have scripting enabled on sites they visit regularly such as GMail, Yahoo, etc.

Thanks to Google, it's easy to find sites hosting PDFs, or to locate PDFs on a specific domain -- MSN, MySpace, Flickr, etc. -- you get the idea.

Adobe has reported that this vulnerability only affects versions of Acrobat Reader prior to version 8, and only on the Windows platform. And they are in the process of preparing patches for earlier releases of Acrobat. Still, there are plenty of people out there who simply never upgrade.

A quick workaround on the client side is to configure your web browser to save PDF files rather than automatically opening them in the browser. Firefox allows you to do this through the Download pane of the Tools/Options dialog, no idea if you can do it with IE.

To protect your own site from being targeted, you could probably configure the web server to manipulate HTTP response headers. Forcing Content-Type: application/octet-stream or even Content-Disposition: attachment should force the user to save the file or launch the viewer outside of the web browser. However, there's no guarantee that all browsers will behave the same way.

Now, how many other browser plugins have similar vulnerabilities? Somehow I doubt we will be waiting very long to find out.

About Chris Eng

Chris Eng, vice president of research, is responsible for integrating security expertise into Veracode’s technology. In addition to helping define and prioritize the security feature set of the Veracode service, he consults frequently with customers to discuss and advance their application security initiatives. With over 15 years of experience in application security, Chris brings a wealth of practical expertise to Veracode.

Comments (0)

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.