You must understand that the attacker doesn’t need to have write access to the specified PDF document.
document.cookie relates to your Google/GMail session.
The above request will cause Acrobat to request
cookie=[your Google/GMail cookie] which can be captured by
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
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.