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:
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
Header add Content-Disposition "Attachment"
IIS (tested in 6.0, these instructions may vary some for older versions of IIS):Change MIME type to "application/octet":
- Start > Run > Enter compmgmt.msc. The Computer Management console appears.
- Right click on the Services and Applications > Internet Information Services (IIS Manager)
- Select Properties > MIME Types
- Scroll down to ".pdf". The MIME type should be "application/pdf". Change this to "application/octet".
- Click OK twice.
Add Content-Disposition header (this must be done by directory or for each PDF file individually):
- In the IIS Management tool (not in Windows Explorer), select a directory with PDF content or an individual PDF file.
- Right-click on the directory or file.
- Select Properties.
- Click the HTTP Headers tab.
- In the Custom HTTP Headers section, click Add.
- A dialog appears. In the "Custom-header name" field enter "Content-disposition". In the "Custom-header value field, enter "Attachment".
- Click OK twice.
- Restart IIS (command line: iisreset).
- 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.