Adobe Acrobat JavaScript Execution Bug

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.

Comments

Common

[jrwr00]

I sure have been seeing alot of javascript bugs lately,
http://it.slashdot.org/article.pl?sid=07/01/01/135 0219

Quick assessment

[also-rr]

The good: It can't remote root your webserver.
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 .pdf.

Let's be clear: bug is in Reader

[fractalus]

The bug is that the Acrobat Reader runs the JavaScript.

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.

Re:Let's be clear: bug is in Reader

[Anonymous Coward]

This kind of thing is why I disable Javascript, along with all the other crap that Adobe like to enable by default, the instant I install Reader (which, unfortunately, I must do from time-to-time). In versions of Reader prior to 8 it was difficult to truly expunge Javascript since, at least under OS X, a message would appear when you closed Reader saying something to the effect of "this document contains javascripts that are vitally important to the functioning of reader -- would you like to turn Javascript on so that the grass is greener and the air smells sweeter? Yes, please make the world a happy wonderful place. No, continue trying to hobble through life with crippled Reader functionality." Or something like that, every time you quit Reader or until you finally relented and re-enabled Javascript.

The solution for Reader 7 was to completely kill off Javascript by deleting a Javascript settings file then create a symlink to /dev/null with the missing file's name:

rm ~/Library/Acrobat\ User\ Data/7.0/JavaScripts/glob.settings.js
ln -s /dev/null ~/Library/Acrobat\ User\ Data/7.0/JavaScripts/glob.settings.js

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 /dev/null required.

Probably Acrobat 8 is safe?

[dawnsnow]

I'm using Acrobat 8 and Firefox 2, and the acrobat plugin displays "This operation is not allowed" when I clicked the pdf link with javascript. Maybe everyone should upgrade their Acrobat reader.

Something like this?

[cliveholloway]

RewriteEngine On
RewriteRule /(.*?)\.pdf\?.*/ /$1.pdf [NC]

(untested)

Re:Something like this?

[brunascle]

wont work. the javascript is after the #, so it's client-side. the server will never see it.

someone on sla.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

[Anonymous Coward]

The exploit works like this:

http://[URL]/[FILENAME].pdf#something=javascript:a lert(123);

Strings after # are not sent to the webserver. That is all client-side.

Make that the Reader Plugin

[Kelson]

Remember, IE uses an ActiveX interface to load Acrobat Reader, while Firefox and Opera use the Netscape-style plugin interface. If the plugin interface is vulnerable, but the ActiveX interface is not, that would explain why it works with Firefox and Opera but not IE.

Also, as others have pointed out, Adobe Reader 8 appears to not be affected.

Re:The whole architecture is fatally flawed

[Thuktun]

Client-side Java isn't necessarily any more secure, since it still has access to the hosting machine via the runtime libraries and JNI. Java *applets* are run in a sandbox, which limits what they can do and makes them more secure than a normal Java application. Perhaps that's what you meant to refer to.

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.