Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
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 More

Adobe Acrobat JavaScript Execution Bug

Comments Filter:

  • Common (Score:2, Informative)

    by jrwr00 ( 1035020 )
    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 (Score:5, Insightful)

      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.

      • Re:The whole architecture is fatally flawed (Score:4, Interesting)

        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.

        • Re: (Score:3, Informative)

          by Thuktun ( 221615 )
          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, havin

          • Re: (Score:2)

            by abigor ( 540274 )
            Yes, I thought it was implied that I was talking about applets, since the OP was ranting against Javascript. Sorry if that wasn't more clear.

          • Re: (Score:2)

            by Heembo ( 916647 )

            Java *applets* are run in a sandbox, which limits what they can do and makes them more secure than a normal Java application.

            Although what you are saying here is true, one must weight the security history of applets in 2006 alone - take a look at my post below, I attached applet vulnerabilities that were posted days ago. Plus take a look at research from Marc Schoenefeld (awesome Java researcher) and Tom Hawtin (scarry smart Java cynic) http://jroller.com/page/tackline [jroller.com] - Java is NOT ready to enterprise prime-time, way way to many ways to escape the sandbox - and just not once or twice, but monthly applet vulnerabilities for t

        • Re:The whole architecture is fatally flawed (Score:4, Interesting)

          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]

          • Re: (Score:2)

            by abigor ( 540274 )
            I never said there were no bugs. I said that the architecture had security in mind. Vulnerabilities like buffer overflows in the VM are a sad fact of life, and of course they'll have to be fixed. But at least the whole architecture isn't broken. Don't confuse architecture defects with coding bugs.

            • Re: (Score:2)

              by Heembo ( 916647 )
              With respect (this time) I submit that due to the long and consistent history of applet sandbox bugs in all vendors JVM's for the last many years, that the architecture for CLIENT side APPLET Java IS fatally flawed. You think corporate america is using Applets for highly secure enterprise applets? No way! Its fundamentally flawed when one call to System.setSecurityManager(null) totally wipes the entire sandbox for all applets running in a JVM.

              Heck, they called setSecurityManager(null) a BUG for NOT WORK
        • 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.
  • 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?

    • Re: (Score:1)

      by slummy ( 887268 )
      Foxit is safe, I can't check the POC on my machine because I don't have Adobe installed. Anyone try Acrobat Linux yet?
      • Yes Acrobat linux seems to be vulnerable to this and in this case we have no way to upgrade to version 8 as it is not available for linux yet. Switching off javascript in the preferences fixes the problem and fortunately, unlike under windows, the application doesn't come up with the message about the lack of javascript crippling functionality.

  • 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.

    • Something like this? (Score:5, Informative)

      by cliveholloway ( 132299 ) on Wednesday January 03, 2007 @05:58PM (#17450966) Homepage Journal

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

      • Re: (Score:2)

        by Kalak ( 260968 )
        From reading the discussions, but not the paper, linked above, I was thinking the exact same thing. Seems kind of annoying to have mod_rewrite check all URLs for the server though, but it would should stop any servers with this from looking like a vector.

        Can anyone see any holes in this logic? A practical use for anything after the .pdf extension?

      • Re:Something like this? (Score:5, Informative)

        by brunascle ( 994197 ) on Wednesday January 03, 2007 @06:02PM (#17451028)
        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.

    • Incorrect httpd Solution (Score:2, Informative)

      by 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.
    • 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.

      Worse, much worse. It allows anyone to execute javascript code as if it was on your server. Another name for that is Cross Site Scripting. This can result in cookie stealing and many other nasty things.

    • You can be clever and read local files [ctho.ath.cx] of unwitting users...

      • Re: (Score:2)

        by TheLink ( 130905 )
        Doesn't seem to do much on my environment: Acrobat reader 4.0, IE6 (with active scripting off, active-x off, and set to download pdf instead of opening in browser).
  • 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).

    • Re: (Score:2)

      by UtucXul ( 658400 )

      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 javasc

  • Let's be clear: bug is in Reader (Score:5, Informative)

    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.
    • "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?

      • Make that the Reader Plugin (Score:5, Informative)

        by Kelson ( 129150 ) * on Wednesday January 03, 2007 @06:29PM (#17451364) Homepage Journal
        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: (Score:2, Interesting)

        by trianglman ( 1024223 )
        From what I have been reading on this it is a bug in how the browser and the reader integrate, not just with the browser and not just with the reader. And I agree, it pains me to say it but it seems that IE handles this correctly (tested myself just to be sure), but I do have to wonder why.
    • how can the sites fix this? the javascript part of the url is after the #, which doesnt get sent to the server.

      • Re: (Score:2)

        by pe1chl ( 90186 )
        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 t
        • IIRC, the fragment part of the URL shows up in a Referer header, but it shouldn't be in the GET or POST request URI (but, interestingly, Apache seems to tolerate it).

          • Re: (Score:2)

            by pe1chl ( 90186 )
            So one can consider that another bug in the reader. It seems to work OK when it is working from a simple pathname (I have never seen GET /directory/filename.pdf#search='keyword'), but when it is reading from a script with parameter(s), it will just pass on the # probably thinking it is part of a parameter value.

    • Re: (Score:1, Informative)

      by 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

  • Probably Acrobat 8 is safe? (Score:5, Informative)

    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.

    • Re:Probably Acrobat 8 is safe? (Score:5, Insightful)

      by origamy ( 807009 ) on Wednesday January 03, 2007 @05:37PM (#17450646) Homepage
      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.

      • Re: (Score:2)

        by antdude ( 79039 )
        I am sure it was designed that way to annoy users to upgrade. :(
        • I select Win95 as my OS and download adobe reader 5.05 because it doesn't have that annoying popup
          I don't know what the reader is on ubuntu, whatever comes up seems to do the trick
      • And not crash. And only load plugins when needed. And not mess with the status bar. And would use close buttons on the title bar like they should be used. And not mess up firefox. And not save PDF files on the temp folder by default. And copy correctly. And not enforce uninforcable anti copying protection. And have a reasonable search method. And use the pointer like it should be. And have normal scrolling behaviour. And not use weird keyboard shortcuts. And have bookmarks etc.

        I probably am still missing a
    • Seconded! Exploit doesn't work with Reader 8

      Same result with Adobe Acrobat Reader 8 with Opera 9.10.
    • I'm using Acrobat 6 and Firefox 2. PDFs open fine and I don't see any abnormal behavior when clicking on the POC link.

  • Which Versions? (Score:1, Interesting)

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

  • Work around? (Score:5, Funny)

    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.
    • 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.
      • Oops, wrong OS, duh. I read that too fast.

        Actually is Adobe's reader any better on Linux, or is the crappiness specific to the Windows version?

        • I haven't seen the Netopsystems FEAD Optimizer on Linux...

          But acroread is still pretty slow and bloated compared to xpdf. It has a few more features (like filling in PDF forms), but I need those features so rarely that I could really just install acroread when I need it, and uninstall it when I'm done.

          Using acroread to view PDFs on Linux is a mistake, generally speaking.

  • Nothing at all happens (other than the PDF opening)... so Vista and Acrobat 8 seem immune.
  • 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? (Score:1, Funny)

    by Anonymous Coward
    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).

    • 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. T

      • Re: (Score:2)

        by Kelson ( 129150 ) *
        Dude... You have to LOG OUT and THEN post anonymously.

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

        • Re: (Score:2)

          by afidel ( 530433 )
          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.

          • Re: (Score:1)

            by makomk ( 752139 )
            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..

            • Re: (Score:2)

              by afidel ( 530433 )
              Correct. The first time I thought it was a cookie or something, so I posted anonymously from my wife's pc which never goes to slashdot but which sits behind my nat'ing router, and my moderation still went poof.
  • 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.

    • 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

      • If IE is not bundled with the OS, how is the average user supposed to download firefox? It's been years since I used ftp to download pretty much anything.

        • If IE is not bundled with the OS, how is the average user supposed to download firefox?

          Using whatever browser the OEM includes: Firefox, IE, Opera, or whatever. The point being since it doesn't come with Windows developers can't assume it will be there and make stupid design decisions based upon that.

      • Re: (Score:2)

        by cdrguru ( 88047 )
        Sorry, IE is here to stay in Windows. Why? Because they dropped WinHelp and created the replacement as HTMLHelp. Can't render HTML without a browser, therefore you can't display help for the OS without IE.

      • Acrobat shouldn't launch a non-default browser and Windows should allow you to disable or remove IE.

        I agree that the default browser should be used, but until I updated to acroread 8, Acrobat would open links in IE. (Swore like heck whenever it happened to me.) It seems to be fixed now, and stuff opens in Opera, like the computer god (or, well, at least me) intends.

        Hope you get the "funny" mods for your second point.

  • 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
  • We should all be safe then considering nobody seems to know how to script in javascript
  • 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

  • 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?

Slashdot Top Deals

Computer programmers never die, they just get lost in the processing.

Close