Slashdot Mirror


Adobe Flaw Heightens Risk of Malicious PDFs

snydeq writes "Security companies warn of a new flaw in version 9 of Adobe Reader and Acrobat that could compromise PCs merely by the opening of a malicious PDF. Although attacks are not yet widespread, hackers are exploiting the flaw in the wild, gaining control of computers via buffer overflow conditions triggered by the opening of specially crafted PDFs." Adobe is calling the flaw "critical" and says a patch for Reader 9 and Acrobat 9 will be released by March 11.

20 of 193 comments (clear)

  1. Sigh... still no basic sandboxing by Ed+Avis · · Score: 5, Interesting

    And why exactly does Adobe Reader run with full permissions to all the user's files? Surely by now Adobe would have learned to run it in a sandbox. For example, the code that reads and renders the PDF could run in a separate process (a la IE8 or Google Chrome) and just send image data back to the main window.

    More generally, the OS needs to make it completely easy to sandbox applications, so even the stupidest application developer can do it with little effort. Indeed, the default should be that it has no access to write files anywhere except those chosen by the user with the Save As box. I'm not holding my breath though...

    --
    -- Ed Avis ed@membled.com
    1. Re:Sigh... still no basic sandboxing by billcopc · · Score: 4, Insightful

      You seem to blindly believe that Adobe is even remotely competent at writing code. If you've ever used Acrobat, you would realize it is a barely-usable resource-thrashing mess.

      Does Ghostview need 150mb of libraries to render a PDF ? No.

      Just because a company is a market leader, does not necessarily mean they know what they're doing. They just know how to sell.

      --
      -Billco, Fnarg.com
    2. Re:Sigh... still no basic sandboxing by bcrowell · · Score: 5, Informative

      And why exactly does Adobe Reader run with full permissions to all the user's files? Surely by now Adobe would have learned to run it in a sandbox. For example, the code that reads and renders the PDF could run in a separate process (a la IE8 or Google Chrome) and just send image data back to the main window.

      You're proposing to attack the problem in the least efficient possible way. This is yet another in a long series of exploits in AR that use the fact that in its default configuration it executes JavaScript embedded in PDFs. The right way to approach this, as a matter of design, would be not to embed a Turing-complete language in a file format that doesn't need it. Once you embed a Turing-complete language in the format, you're giving the bad guy the ability to run any code he wants on the user's machine. The moral of Turing's theorem is that it's essentially impossible to have any automated check that determines what a piece of code will actually do when you execute it. So yeah, you can try to sandbox it, but that's a last resort.

      You're comparing with a web browser. A web browser is qualitatively different. In a web browser, the user (a) wants to be able to run javascript code, and (b) expects that such a thing will happen. In a PDF reader, there is typically no reason for the reader to want it to run JS, and the reader has no sane reason to expect it to run JS. Actually, the reason Adobe made AR execute JS by default was that it wanted to be able to do things that are inherently inimical to the user's interest. JS allows the creator of the PDF to determine who's reading the document, and also provides a mechanism for DRM. Lots of people who create PDFs want to believe in the DRM fable that they can give a document to other people, but then control the use of the document after that. As with all DRM, it's inherently impossible to make it work right as long as the user has hardware that they're really allowed to use as a general-purpose PC. E.g., to remove the DRM from a PDF on a linux box, you can do this: gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=b.pdf a.pdf -c '.setpdfwrite'

      As a user, there are basically two sane things you can do. (1) Don't install AR on your machine. Use something else, such as evince on linux, or foxit on windows. They're faster anyway. (2) If there really is extra functionality in AR that you need, turn off JS. To disable js, go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript".

  2. I've experienced this by tygerstripes · · Score: 4, Funny

    I just tried to open a .pdf in Reader 9, and it's completely locked up - I've been stuck on the splash screen for 20 minu--

    Oh wait, it's opened now. False alarm, sorry.

    --
    Meta will eat itself
  3. Re:What about Foxit? by jetsci · · Score: 4, Informative

    This is Slashdot. Right so far. We are mostly alternative OS users, i.e., Linux, *BSD, OSX, etc(sorry OS2 users). Right again. These articles are annoying in that they are so very broad. Its like the typical American-slashdotter who assumes the "Government" refers to the U.S. only in any context. This article presumes the user base is that of Windows users. Why not specify this is a ****OS NAME HERE***** issue? The article says this is a Windows XP SP3 issue. Great, that's nice to know, but I shouldn't be presented with an article that makes me think I need to go and update/remove Adobe from my Debian machine. Pure FUD. FUD' beyond belief! /rant

    --
    Bored at work? Play Game!
  4. Patch by March something? by rjune · · Score: 5, Interesting

    Today is February 20. This is listed as a critical flaw and they are taking 18 days to release a patch. I'm glad they're getting right on this.

  5. Adobe should separate pdf and acrobat more by goombah99 · · Score: 4, Interesting

    PDF has become what it set out to be, the de facto truly portable document format.

    The problem is acrobat keeps larding in new features all the time to the point where in a corprorate environment you get more and more pdfs that require acrobat to even see.

    it's an embrace and extend approach.

    the problem here is the problem microsoft occasionally runs into-- if you monocrop then their is huge exposure to the possibility that viruses can spread like wild fire.

    But with microsoft we were always in that boat from the first day they introduced it. microsoft docs always went hand in hand with the application software environment creating a stable ecosystem for any potential virus. (I use the term virus liberally)

    with pdf this was not the case. Pdf is a format. there are many readers.

    but adobe's constant racheting of add ons is threatening this.

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:Adobe should separate pdf and acrobat more by fuzzyfuzzyfungus · · Score: 4, Insightful

      There are, already, standardized subsets of PDF( PDF/A, PDF/X, PDF/E) which fulfill your request.

      Trouble is, while Adobe does have an incentive to support those, they have no incentive to encourage them as defaults. There are two basic problems: Adobe has an incentive to spread PDF as widely as possible(which creates a strong pressure to tack on additional functions to address expanded use cases) and Adobe only makes money on PDF if you use their software. If, in practice, you can only be confident of being able to manipulate a given PDF with Acrobat, Adobe cashes in. Otherwise, not so much.

    2. Re:Adobe should separate pdf and acrobat more by Permutation+Citizen · · Score: 5, Informative

      - If you want a format ISO standardized.
      - If you need long term archiving, being sure that after several years your document will be the same even if your computer and your printer have changed.
      - If you don't need fancy new stuff, video, sounds.
      - But you still want wide support PDF has for reading and printing everywhere.

      Then use PDF/A.

      This is a subset of PDF. It can be produced by Acrobat, but also a wide range of other vendors applications and scanners, including OpenOffice.

  6. Re:What about Foxit? by InsertWittyNameHere · · Score: 5, Funny

    Foxit has compatibility problems because it doesn't have all of the features of Adobe Reader 9.

    For example it doesn't open the specially crafted PDFs our clients send us at work, which are thoughtfully secured with AntivirusXP2009

  7. March 11? by Culture20 · · Score: 4, Insightful

    That's three weeks away! One week from now, pdfs are going to be on every questionable web page and email attachment. Step up the cycle, Adobe.

  8. try a non-Adobe PDF reader by macraig · · Score: 4, Informative

    I'm using a non-Adobe PDF reader: Foxit Reader. It's commercial and not open source, but the non-Pro version is free to use; it's functionally far superior to the open source ones that were mentioned at Slashdot recently. I really hope the OSS projects can reach the level of sophistication of Foxit, because it's really my baseline of minimum PDF-reader functionality. The first OSS reader that can duplicate Foxit's sophistication will get a new convert.

  9. Patched by March 11th... unless you're using v8 by myxiplx · · Score: 4, Informative

    Great, I've got to wait 2-3 weeks for this to be patched.

    Oh wait, Adobe have a 4 MONTH OLD bug that means we can't even run Acrobat 9 within our company:
    http://www.adobe.com/go/kb404597

    *seethes*

    What's worse is that Autodesk hit this exact same bug with their beta of Design Review, and fixed it within a couple of weeks, so I know there's a fix for this.

  10. Re:What about Foxit? by pipatron · · Score: 4, Funny

    I use AmigaOS, you insensitive clod.

    --
    c++; /* this makes c bigger but returns the old value */
  11. Re:What about Foxit? by Anonymous Coward · · Score: 5, Informative

    The problem is a buffer overflow + using javascript to fill the overflow with shell code (which is OS/CPU specific). I just did a test on x86 linux and acrobat reader for linux is affected as well.

  12. Does Data Execution Prevention stop the attack? by Myria · · Score: 4, Informative

    Does hardware Data Execution Prevention stop it from happening, in that this exploit would crash Reader instead of cause an exploit if DEP is enabled? I wish companies would suggest that as a possible mitigation, even if not all computers support it.

    I did dumpbin /headers and saw that the EXE header for AcroRd32.exe has the "NX compatible" bit set. This means that DEP will be automatically enabled for Reader on Vista.

    However, that doesn't cover XP. XP 32 SP3 has an API call named SetProcessDEPPolicy to request enabling DEP for your process. Adobe should modify Reader to call this function if it exists. (It exists on Vista SP1 as well, but Vista SP1 will already enable it due to /NXCOMPAT.)

    XP 32 SP2 and XP 64 SP2, even though they have DEP, don't have a way to enable it if the system-wide DEP setting is "opt in" - the default. And there's no way to opt in that these support. (Google Chrome has code to use an undocumented system call to enable it, but it actually has no effect.)

    --
    "Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
  13. Re:What about Foxit? by A.+B3ttik · · Score: 4, Informative

    Sumatra PDF Reader is Open Source, less than half the size of Foxit (1/15th the size of Acrobat) and has search, text-read, copy-paste, and plenty of keyboard shortcuts. It's very quick and streamlined and makes Foxit look bloated in comparison.

    Right now it's windows only, unfortunately.

    http://blog.kowalczyk.info/software/sumatrapdf/index.html

  14. Re:What about Foxit? by PotatoFarmer · · Score: 4, Informative

    On the other hand, the actual advisory from Adobe states that the issue affects all platforms. You'd think they'd be the ones to know best, right?

  15. Re:What about Foxit? by stonewallred · · Score: 5, Informative

    the "nice" feature on this is that you can copy and paste protected documents.

  16. Comment removed by account_deleted · · Score: 4, Informative

    Comment removed based on user account deletion