Adobe Acrobat JavaScript Execution Bug 94
QASec.com writes to mention that Stefano Di Paola and Giorgio Fedon discovered an unpatched vulnerability in Adobe Acrobat Reader that can allow an attacker to execute arbitrary JavaScript on any hosted PDF file. People are reporting different results based on browser and Acrobat versions. Most of the major sites discussed have already fixed the problem, but many smaller sites may still need to be patched.
Common (Score:2, Informative)
http://it.slashdot.org/article.pl?sid=07/01/01/13
Quick assessment (Score:5, Informative)
The bad: It can make your webserver appear to be hosting arbitrary content if you are hosting any PDF files and the user is using Acrobat reader.
The solution: Delete every PDF file hosted by your webserver OR configure your httpd to throw nasty errors for any requests that contain a string after the
Let's be clear: bug is in Reader (Score:5, Informative)
Sites are "fixing" this by implementing work-arounds on the server to refuse serving the file if the script is tacked onto the URL. But these are kluges, stop-gap measures to reduce the damage until a proper patch can be made. The sites are not vulnerable; the reader is.
Probably Acrobat 8 is safe? (Score:5, Informative)
Something like this? (Score:5, Informative)
Re:Something like this? (Score:5, Informative)
someone on sla.ckers.org [ckers.org] had a good suggestion: redirecting to a random, one-time address (that translates to the right PDF file on the server-side) if the client requests the PDF file directly. the valid addresses would have to be hard to guess, though.
Incorrect httpd Solution (Score:2, Informative)
http://[URL]/[FILENAME].pdf#something=javascript:
Strings after # are not sent to the webserver. That is all client-side.
Make that the Reader Plugin (Score:5, Informative)
Also, as others have pointed out, Adobe Reader 8 appears to not be affected.
Re:The whole architecture is fatally flawed (Score:3, Informative)
However, to get full-page interaction of controls that you would get using Javascript, your applet would have to present the entire page itself, rather than being embedded in a page. In that respect, having declarative HTML controls with Javascript processes is more lightweight and scalable than using applets.
Plus, applets were architected to do asynchronous server-side requests separate from the main browser navigation, which is exactly what AJAX accomplishes for DHTML pages.
Re:Let's be clear: bug is in Reader (Score:1, Informative)
The solution for Reader 7 was to completely kill off Javascript by deleting a Javascript settings file then create a symlink to
rm ~/Library/Acrobat\ User\ Data/7.0/JavaScripts/glob.settings.js
ln -s
This was a bit brutal, but worked pretty well. Reader 8 no longer effectively requires Javascript the way way 6 and 7 did. You can simply disable it, along with "features" like allowing PDFs to launch external files, run movies, and other opportunities for mischief, right from within the preferences. No symlinks to