Cross-Site Scripting in Adobe Plug-In

You may have seen the recent flurry of news stories surrounding a cross-site scripting (XSS) vulnerability in Adobe's PDF browser plug-in. In case you missed it, here are a few articles that provide an overview of the problem:

Washington Post
USA Today
Information Week

Essentially, the vulnerability provides yet another way for an attacker to execute JavaScript in another user's browser when the user follows a specially crafted URL to a PDF file. By adding JavaScript commands to parameters in the URL, attackers can steal cookies and sensitive data, change the appearance or behavior of the site, and redirect users off-site in phishing attacks. To make matters worse, the attack string (the part that does the damage) in the URL is never even sent to the web server, so the attack can't be stopped by having the server look for dangerous JavaScript in requests for PDF files.

So, what can an organization do to protect its users from being attacked through PDF files stored on its web site? There is no foolproof solution, but the best approach is trying to prevent the vulnerable Adobe browser plug-in from running, which can be accomplished in some browsers by changing HTTP headers in the web server response. There are two relevant headers that could be changed:

  Content-Type: application/octet
  Content-Disposition: Attachment

Both of these headers instruct the browser to download the file instead of opening it in the vulnerable Adobe plugin. We have followed this approach on our own servers and it prevents the attack in most cases. This morning, Google and Yahoo followed suit with a similar fix.

Here are instructions for adding these headers to the server response for PDF documents in Apache and IIS.

Apache:

Add these lines to the httpd.conf file inside the <Directory> tags.

  AddType application/octet .pdf
  <Files *.pdf>
    Header add Content-Disposition "Attachment"
  </Files>

IIS (tested in 6.0, these instructions may vary some for older versions of IIS):

Change MIME type to "application/octet":

1. Start > Run > Enter compmgmt.msc. The Computer Management console appears.
   
2. Right click on the Services and Applications > Internet Information Services (IIS Manager)
   
3. Select Properties > MIME Types
   
4. Scroll down to ".pdf". The MIME type should be "application/pdf". Change this to "application/octet".
   
5. Click OK twice.

Add Content-Disposition header (this must be done by directory or for each PDF file individually):

1. In the IIS Management tool (not in Windows Explorer), select a directory with PDF content or an individual PDF file.
   
2. Right-click on the directory or file.
   
3. Select Properties.
   
4. Click the HTTP Headers tab.
   
5. In the Custom HTTP Headers section, click Add.
   
6. A dialog appears. In the "Custom-header name" field enter "Content-disposition". In the "Custom-header value field, enter "Attachment".
   
7. Click OK twice.
   
8. Restart IIS (command line: iisreset).
   
9. Check that PDF content from the browser now prompts the user to "download" rather than simply opening the content.

This is not a 100% solution, but changing the HTTP response headers will go a long way toward reducing the risk to users of your site. Although this works in current versions of the more popular browsers, it is possible that some browsers could ignore these headers and open the PDF with the Adobe plugin anyway.

It may also be possible to address the vulnerability programmatically. Some examples have been published for Java and .Net. These examples have not been tested by Security PS, but they have been proposed as a way to help prevent attackers from exploiting the Adobe plug-in vulnerability.

If you implement these or other changes, please let us know about your experience.