Forgot your password?
typodupeerror
Security Bug

Adobe Acrobat JavaScript Execution Bug 94

Posted by ScuttleMonkey
from the oops dept.
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.
This discussion has been archived. No new comments can be posted.

Adobe Acrobat JavaScript Execution Bug

Comments Filter:
  • i see... (Score:0, Offtopic)

    by User 956 (568564) on Wednesday January 03, 2007 @05:15PM (#17450310) Homepage
    Adobe Acrobat JavaScript Execution Bug

    So that's what happened to Saddam the other day... now it all makes sense.
  • Common (Score:2, Informative)

    by jrwr00 (1035020) <jrwr00 @ g m a i l . com> on Wednesday January 03, 2007 @05:20PM (#17450382) Homepage
    I sure have been seeing alot of javascript bugs lately,
    http://it.slashdot.org/article.pl?sid=07/01/01/135 0219 [slashdot.org]
    • by Anonymous Coward on Wednesday January 03, 2007 @05:47PM (#17450792)
      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.
      • by abigor (540274) on Wednesday January 03, 2007 @06:23PM (#17451280)
        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.
        • by Anonymous Coward on Wednesday January 03, 2007 @06:27PM (#17451344)
          I seem to remember about a billion security bulletins from Sun and patches and versions that wouldn't be patched. All that coupled with apps that would only work with 1.3.1 (which was unpatched) and apps that only work with 1.5, etc. No thanks! Java on the client didn't do so well because Sun made it a damn mess.
        • by Thuktun (221615) on Wednesday January 03, 2007 @07:40PM (#17452092) Homepage Journal
          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.
        • by Heembo (916647) on Wednesday January 03, 2007 @09:25PM (#17452976) Journal
          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]
        • by oohshiny (998054) on Wednesday January 03, 2007 @11:55PM (#17454072)
          It was addressed back in the '90s. It's called client-side Java.

          Not really; over the last decade, people have found numerous security holes, not only in Sun's implementation, but also in the underlying Java design.

          Maybe if the start-up problems in the VM are addressed, client-side Java will return

          I think J2SE is far too bloated for that. But J2ME/MIDP might make a good basis for reviving applets.
      • by Anonymous Coward on Wednesday January 03, 2007 @06:24PM (#17451304)

        It's not a javascript bug - its a pdf bug. As far as I'm concerned it's just one more reason to hate PDFs in browsers.

  • by JeanBaptiste (537955) on Wednesday January 03, 2007 @05:22PM (#17450412)
    i know some people that are gonna get pranked tonight.

    how do they find these things?
  • Foxit? (Score:3, Interesting)

    by phalse phace (454635) on Wednesday January 03, 2007 @05:24PM (#17450434)
    Does this also affect Foxit reader, or is this just exclusive to Acrobat?
  • Quick assessment (Score:5, Informative)

    by also-rr (980579) on Wednesday January 03, 2007 @05:24PM (#17450442) Homepage
    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.
  • by Yvan256 (722131) on Wednesday January 03, 2007 @05:24PM (#17450448) Homepage Journal
    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).

    • by UtucXul (658400) on Wednesday January 03, 2007 @05:30PM (#17450530) Homepage
      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).
      I don't think this would affect Preview on OS X or xpdf since neither of them handle all the javascript that Acrobat Reader 6 and above can handle. I haven't used Preview much, so I could be wrong, but since I tend to use pdfs for slides for talks, and I embed movies using javascript (pdfanim and LaTeX), I have experimented with javascript abilities in the various viewers. I also just skimmed the linked page, so I could be totally wrong in everything I said. But I don't think so.
  • by fractalus (322043) on Wednesday January 03, 2007 @05:26PM (#17450472) Homepage
    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.
    • by PatPending (953482) on Wednesday January 03, 2007 @05:45PM (#17450762)
      "bug is in Reader" Huh? TFA mentions the DOM. And a link from TFA had this follow-up: Works on:
      Firefox 2.0.0.1 win32
      Firefox 1.5.0.8 win32
      Opera 8.5.4 build 770 win32
      Opera 9.10.8679 win32
      But doesn't work here on IE6 or IE7.
      My Firefox was updated this a.m. to 1.5.0.9 and it was not affected. The Reader remains the same. BTW, I wonder how much credit the IE7 team gets for not being affected by this?
    • by brunascle (994197) on Wednesday January 03, 2007 @05:52PM (#17450866)
      how can the sites fix this? the javascript part of the url is after the #, which doesnt get sent to the server.
      • by pe1chl (90186) on Wednesday January 03, 2007 @06:39PM (#17451486)
        That depends. It looks like at least some browsers send the # to the server when it is part of a parameter, not something that looks like a pathname.

        On our website we have a directory with .pdf files. On the site there are two kinds of links to it:

        1. of the form /directory/filename.pdf which return the content as application/pdf which normally results in an embedded reader window. intended to view the document.

        2. of the form /directory?file=filename.pdf which is handled by an index.php in the directory that processes the ?file= arg (ofcourse checking that it does not try to refer a file outside of the directory) and sends the file with a Content-disposition: attachment; filename="filename.pdf" header, which normally results in a popup to save the file.

        Now I have found that sometimes we get references to URL of the form /directory?file=filename.pdf#search='searchkeyword '
        It turns out that this happens when the user has selected that second form (which is intended for downloading the pdf rather than viewing it), then still selected it to be "opened by the application" from the browser save-file popup, and then performed a search operation inside the reader.
        I found this a rather interesting form of information leakage, as you can see what search terms the users are using on your pdf... it must be intentional.

        Maybe in this case that particular behaviour can be used by having URL of the form /directory?file=filename.pdf and the index.php (or .pl or whatever scripting language you like) sending just the mime type and the file, not the content disposition.
        Disadvantage of course is that the reader cannot load partial data as it normally does when it is reading from a file.
    • by Anonymous Coward on Wednesday January 03, 2007 @08:04PM (#17452318)
      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.
  • by dawnsnow (8077) on Wednesday January 03, 2007 @05:28PM (#17450488)
    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.
  • Which Versions? (Score:1, Interesting)

    by born4fun (1045582) on Wednesday January 03, 2007 @05:28PM (#17450492)
    The story doesn't tell which versions are hit. Is it the latest version (8)?
  • by Cr0w T. Trollbot (848674) on Wednesday January 03, 2007 @05:30PM (#17450522)
    After Do Electric Sheep Dream of Civil Rights? and A Shopping-Scanner Darkly, I was hoping for another Philip K. Dick title reference from ScuttleMonkey here. "'Squash My JavaScript Bugs,' the Acrobat said", perhaps? The Acrobat Whose JavaScript Bugs Were All Exactly Alike? JavaScript Bugs of the Acrobat Moon?

    Crow T. Trollbot

  • by Anonymous Coward on Wednesday January 03, 2007 @05:31PM (#17450546)
    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.
    • by MillionthMonkey (240664) on Wednesday January 03, 2007 @06:13PM (#17451162)
      If you ever do decide you want Acrobat again, you'll have to run the Adobe Acrobat Reader 7.0 installer. And then four more installers to climb up the versions from 7.0.1 through 7.0.8 or whatever it is now. And then the final installer to fix this vulnerability.

      Or you can find the 5.0 version somewhere, from happier days. Somebody at Adobe really has their head up their ass.
    • by Anonymous Coward on Wednesday January 03, 2007 @06:41PM (#17451510)
      you forgot:
      ln `which xpdf` /usr/bin/acrobat
    • by Anonymous Coward on Thursday January 04, 2007 @10:47AM (#17457836)
      Novell/SuSe, as always, was the first to remove xpdf in favor of Acrobat Reader (there is *More* to acrobat than the reader ;)), which is closed source, but luckily you can't go ahead and accidentially print PDFs with the no-print bit set. Phew.

      And at about the same time, Novell/SuSE started running portable dot Net from the init scripts and "Registering IL executables". While Mono was funded.

      Need more proof to understand that Novell is dead for the linux community?
  • by MSFanBoi2 (930319) on Wednesday January 03, 2007 @05:36PM (#17450632)
    Nothing at all happens (other than the PDF opening)... so Vista and Acrobat 8 seem immune.
  • by porkchop_d_clown (39923) <mwheinz@@@me...com> on Wednesday January 03, 2007 @05:37PM (#17450642) Homepage
    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.
  • by Anonymous Coward on Wednesday January 03, 2007 @05:50PM (#17450834)
    >Most of the major sites discussed have already fixed the problem,
    >but many smaller sites may still need to be >patched.

    This is a client side problem. The worst part is... that the part of the URL after the hash is never sent to the server (which in what holds the malicious code) so there is little that can be done on the server side.

    One possible work around on the server side:
    Direct your web server to serve .pdf files as mime type "application/octet"
    That way the files will be saved to disk instead of opening in the browser plug in.
    • by Kelson (129150) * on Wednesday January 03, 2007 @06:35PM (#17451440) Homepage Journal
      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".

      • by Anonymous Coward on Thursday January 04, 2007 @06:37AM (#17456056)
        The only problem with that solution is IE/Opera. Both will either sniff the content or guess based on extension and open with the plugin. Serving PDFs with an unknown MIME type like application/x-not-a-pdf will take care of Opera (and degrade nicely for clients that properly respect application/octet-stream), but IE needs a Content-disposition: attachment header to make it stop trying to be 'helpful'.
  • by Anonymous Coward on Wednesday January 03, 2007 @05:54PM (#17450888)
    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).
    • by pclminion (145572) on Wednesday January 03, 2007 @06:21PM (#17451258)

      Dude... You have to LOG OUT and THEN post anonymously.

      As for why the points aren't given back to you... It prevents the typical abuse where some idiot moderates a stupid post, then waits a few minutes to let other idiot moderators see it. Moderators typically moderate up posts which have already been modded up. So you wait until everyone else pushes your target post up to '5', then you post a comment which undoes your moderation. So you keep your mod points but you can control which posts get modded up. The solution to the stupidity is to not give you back your mod point.

      • by Kelson (129150) * on Wednesday January 03, 2007 @07:32PM (#17452006) Homepage Journal
        Dude... You have to LOG OUT and THEN post anonymously.

        Another option is to keep a second browser around that's not logged in.

        • by afidel (530433) on Wednesday January 03, 2007 @10:22PM (#17453384)
          Actually neither works with current Slashcode, if a post is made from the same IP (possibly in a set period of time, haven't dug into it) then the moderation is removed. Sucks if you are at a big company with a proxy server, but it prevents the anonymous abuse hole you are talking about.
          • by makomk (752139) on Thursday January 04, 2007 @07:06PM (#17466474) Journal
            Actually neither works with current Slashcode, if a post is made from the same IP (possibly in a set period of time, haven't dug into it) then the moderation is removed. Sucks if you are at a big company with a proxy server, but it prevents the anonymous abuse hole you are talking about.

            So let me get this straight... if anyone in my university halls posts to a Slashdot thread within a certain timespan of me moderating it, my moderation will be silently undone? (There's a *really* nasty NAT setup there...)
  • by id (11164) on Wednesday January 03, 2007 @05:56PM (#17450924) Homepage
    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 (Score:5, Interesting)

    by LiquidCoooled (634315) on Wednesday January 03, 2007 @05:57PM (#17450946) Homepage Journal
    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.
    • by 99BottlesOfBeerInMyF (813746) on Wednesday January 03, 2007 @06:35PM (#17451444)

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

      It sounds like your problem is with Acrobat Reader, Windows, and IE. Acrobat shouldn't launch a non-default browser and Windows should allow you to disable or remove IE. For that matter, IE should not be bundled in the first place, so that developers don't rely upon it being there and develop their applications to be browser independent.

      PDF itself is just a format, and a nice one. Since I would never browse general Web sites with Windows, let alone with acrobat installed, I don't have to worry about that problem.

  • by Anonymous Coward on Wednesday January 03, 2007 @06:05PM (#17451066)
    There is no way to patch this on the server side since this is a client side vuln in adobe reader. BTW I posted this story and never said that :)
  • by 140Mandak262Jamuna (970587) on Wednesday January 03, 2007 @06:08PM (#17451098) Journal
    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.

    • Or rather, the way you install them is.

      The main difference between this and a Firefox Extension is the Firefox makes you wait a few seconds and then click on the "I want to do something really stupid" button. Adobe figures that most people don't care, and presses the "I want to do something really stupid" button FOR you.

      My experience as a system administrator is that the only way to get people to quit pushing the "I want to do something really stupid" button, is to make it more inconvenient to jump through the hoops and push the button than to download the file and launch it from the desktop or shell.

      Firefox is nearly there.
  • by Anonymous Coward on Wednesday January 03, 2007 @06:25PM (#17451318)
    Given how bloated Acrobat Reader had become, I had already stripped out half the plug-ins and disabled Javascript within Reader anyway. It is rarely used and it was an obvious accident waiting to happen, security wise.
  • by zakeria (1031430) on Wednesday January 03, 2007 @06:35PM (#17451448) Homepage
    We should all be safe then considering nobody seems to know how to script in javascript
  • by Vandil X (636030) on Wednesday January 03, 2007 @07:49PM (#17452174)
    They may as well, seeing as they've posted no real Apple bugs to date.
  • FIle Under, "Duh" (Score:5, Insightful)

    by ewhac (5844) on Wednesday January 03, 2007 @08:36PM (#17452640) Homepage Journal
    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

    • by Anonymous Coward on Wednesday January 03, 2007 @11:41PM (#17453982)
      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.

      Do you complain this much about javascript in HTML? After all the web was around and working before javascript.

      Would you prefer a proprietary language that only for use in Adobe products? I think they did the right thing and opened up making dynamic PDF files with a standard language.

      JS in PDFs is really handy for offering field validation. Also you can import AutoCAD documents and make them dynamic.
      • by ewhac (5844) on Wednesday January 03, 2007 @11:57PM (#17454100) Homepage Journal
        Do you complain this much about javascript in HTML?

        Yes.

        JavaScript was an amazingly stupid idea there, too, because it takes what was originally supposed to be a document (i.e. a static presentation of information) and turns it into software, with all the attendant hazards. I keep JavaScript turned off by default.

        The macro viruses that plagued Microsoft Word showed exactly what kind of trouble would inevitably follow if you turned documents into software, but tried to pretend they were still "documents". But apparently no one was willing to learn that lesson. So now we're stuck with JavaScript, pop-up ads, pop-under ads, auto-playing music, and a host of other garbage. Now Adobe seems intent on doing the same thing to PDFs.

        Schwab

    • by Anonymous Coward on Thursday January 04, 2007 @11:00AM (#17457988)
      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 comment I read on one of the linked blogs suggests that this is not the case -- implying that the URL javascript executes even if the javascript option is turned off inside of Acrobat. Haven't checked this myself, though.
  • by julesh (229690) on Thursday January 04, 2007 @05:12AM (#17455710)
    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?

In 1869 the waffle iron was invented for people who had wrinkled waffles.

Working...