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.

Common

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

The whole architecture is fatally flawed

Pardon me, but I am just sick of all this javascript nonsense. While the goal is notable, the design REALLY needs to be rethought and redone, from scratch. But this time with security in mind. It's quite clear that the original designers didn't have a clue about security. And the current batch, I'm sad to say, still doesn't take it seriously.

Yes, I know that those are strong words. But there has never been a secure implementation of anything where security was an afterthought, and bolted on later. Javascript is no exception.

Javascript has well shown that its approach can be very useful. But honestly, right now it seems almost as problematic as Microsoft Windows, when it comes to security issues. Frankly, the Open Source community really ought to be doing better here.

This is (IMHO) the biggest problem with the current implementation of all the Web 2.0/AJAX approaches. And until it's PROPERLY addressed, we're going to see a continual repeat of security issues, just like we see with MS Windows. It's not new; people have been saying this for years. And we still keep seeing these problems.

Pardon the rant, but I really do get tired of seeing this stuff when it should never have happened to begin with.

Re:The whole architecture is fatally flawed

It was addressed back in the '90s. It's called client-side Java. The VM was slow to start up (it still is), and it faced hostility from Microsoft. But security was an uppermost concern, and the whole architecture is pretty nice. Maybe if the start-up problems in the VM are addressed, client-side Java will return (it's wholly server-side now, except for a few standalone apps here and there) and we'll see an end to this silly Ajax stuff.

Re:The whole architecture is fatally flawed

OMG you are smoking Java crack there boy. Client side Java has more vulnerabilities than... Javascript. I love Java, but keep it on the server where it belongs. MySpace is getting ready to consider migrating from .NET to Java, it's solid on the server. But on the client... nope.

Take this from the LAST sunsolve weekly report:

Newly Released Sun Alert Notifications

Sun Alert ID: 102729 (RESOLVED)
Synopsis: Security Vulnerabilities in the Java Runtime
                              Environment may Allow Untrusted Applets to Elevate
                              Privileges and Execute Arbitrary Code
Product: Java 2 Platform, Standard Edition
Category: Security
Date Released: 19-Dec-2006
Date Closed: 19-Dec-2006

To view this Sun Alert document please go to the following URL:
http://sunsolve.sun.com/search/document.do?assetke y=1-26-102729-1 [sun.com]

Sun Alert ID: 102731 (RESOLVED)
Synopsis: Security Vulnerabilities Related to Serialization
                              in the Java Runtime Environment may Allow Untrusted
                              Applets to Elevate Privileges
Product: Java 2 Platform, Standard Edition
Category: Security
Date Released: 19-Dec-2006
Date Closed: 19-Dec-2006

To view this Sun Alert document please go to the following URL:
http://sunsolve.sun.com/search/document.do?assetke y=1-26-102731-1 [sun.com]

Sun Alert ID: 102732 (RESOLVED)
Synopsis: Security Vulnerabilities in the Java Runtime
                              Environment may Allow an Untrusted Applet to Access
                              Data in Other Applets
Product: Java 2 Platform, Standard Edition
Category: Security
Date Released: 19-Dec-2006
Date Closed: 19-Dec-2006

To view this Sun Alert document please go to the following URL:
http://sunsolve.sun.com/search/document.do?assetke y=1-26-102732-1 [sun.com]

that is really neat

i know some people that are gonna get pranked tonight.

how do they find these things?

Foxit?

Does this also affect Foxit reader, or is this just exclusive to Acrobat?

Quick assessment

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.

Something like this?

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

(untested)

Re:Something like this?

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

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.

OS X

Does this affect Preview on OS X too? After all, pratically all OS X users will use Preview to view PDF files (since Preview comes with OS X, and OS X itself has a PDF renderer built-in, at least from what I've read/understood).

Let's be clear: bug is in Reader

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.

Make that the Reader Plugin

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.

Probably Acrobat 8 is safe?

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.

Re:Probably Acrobat 8 is safe?

People *would* upgrade their Acrobat Reader, if they hadn't turned off that horrendous update screen that pops up every single time you open a PDF file.
Adobe could surely learn how to make a more user friendly "update is available" screen, kinda like Firefox does.

Which Versions?

The story doesn't tell which versions are hit. Is it the latest version (8)?

Work around?

It's typical that they don't mention any work around. I'll be the first to put one up; first open up a command prompt then run

  chmod -x `which acrobat`
  rpm --erase acrobat
  rpm --install xpdf

there, couldn't be simpler. If you find these commands don't work on your system, you either need to use the "apt" command instead of "rpm" or upgrade your operating system. If you are running OpenBSD and you've managed to install and run acrobat then you don't need my instructions.

Nothing happens under Vista with Acrobat 8...

Nothing at all happens (other than the PDF opening)... so Vista and Acrobat 8 seem immune.

Wait, wait, wait

Why did these villains publicize an unpatched exploit? Why didn't they go through normal channels [slashdot.org]?

I question the timing [slashdot.org]. What are they trying to prove, by doing this? They must be trying to profit from it [slashdot.org].

Oh, wait, this is about Adobe and not Apple. Nevermind.

What the hell?

What the fuck is with this bullshit that posting ANONYMOUSLY still cancels out any moderations you have made? Oh, and better still, those points are wasted forever instead of being given back to you (which is what "Undone" like it fucking says would imply).

sla.ckers.org

This also being discussed at sla.ckers.org [ckers.org] along with a useful suggestion for keeping yourself safe from a lot of these type vulnerabilities.

I don't like PDF

I recently signed up for the "send your name to wherever" thing pointed out on slash (its in my comment history somewhere)
The PDF was formed with parameters linking to a second pdf base document.

From Firefox on Windows with internet explorer disabled the pdf opened inside acrobat then proceeded to display the resulting PDF file in internet explorer.

I haven't seen IE now for ages and that made me nervous as hell.

Firefox extension anyone?

Would someone please write a quick Extention to Firefox to chop truncate links to pdf documents to remove the #some_string=javascript:spoofed_script

Please?

I should find where I had saved the firefox extension development SDK and learn it.

JavaScript error

We should all be safe then considering nobody seems to know how to script in javascript

Also to be called the 3rd Month of Apple Bug?

They may as well, seeing as they've posted no real Apple bugs to date.

FIle Under, "Duh"

It was inevitable this would happen ever since Adobe made the impossibly stupid move of adding JavaScript to their reader. Really, I can't heap enough well-deserved derision on this boneheaded, lame-brained, imbecilic, preposterous, self-serving, idiotic, fucktarded idea.

Every time I install Acrobat Reader, I dive through the preferences panel and fix all the incorrect defaults. One of the things I turn off, and which should be off by default, is JavaScript execution. Whether turning this off will protect against the described vulnerability, I don't know, but it's probably a reasonable first line of defense.

A lot of the factory-default settings in Acrobat Reader are (stupidly) wrong. You should review all of them.

Schwab

More info?

There's a lot of missing information here.

1. What context does the js execute in? Browser or Acrobat? If Acrobat, does it have access to your cookies? (I'd guess not)
2. What versions/browsers are affected? I'm using FF2 with Acrobat 5, and nothing seems to happen, but this could be because I've got an odd setup.

Anyone know?

Re:This is a client side problem

One possible work around on the server side: Direct your web server to serve .pdf files as mime type "application/octet"

Most people in a position to implement that idea probably know this already, but for those who aren't, the typical MIME-type for generic downloads is "application/octet-stream".