Slashdot Mirror


New Method Could Hide Malware In PDFs, No Further Exploits Needed

Trailrunner7 writes "A security researcher has managed to create a proof-of-concept PDF file that executes an embedded executable without exploiting any other security vulnerabilities. The PDF hack, when combined with clever social engineering techniques, could potentially allow code execution attacks if a user simply opens a rigged PDF file. With Adobe Reader, the only thing preventing execution is a warning. Disabling JavaScript will not prevent this."

15 of 234 comments (clear)

  1. Re:PDF-XChange by Monkeedude1212 · · Score: 2, Interesting

    He says that it works in other PDF Readers (well he mentioned one, Foxit) - because he's not exploiting a vulnerability in any of the applications, but the PDF Language itself.

    So, chances are, you are just as vulnerable. He also said he reported it to Adobe, without releasing his proof of concept to the public - so we'll see what comes out of it.

    It might just end up that Adobe products become more secure for reading PDFs than the others, and Adobe then has an upper hand.

    [tinfoil speculation]
    And if thats the case, why would they inform other PDF Readers. And unless the proof of concept is made public, how do we know there is actually a vulnerability besides the word of this hacker and Adobe?
    [/tinfoil speculation]

  2. With Foxit Reader by wiredog · · Score: 5, Interesting

    There's no warning at all. It just runs.

  3. Re:PDF-XChange by Anonymous Coward · · Score: 1, Interesting

    If you read the comments under the original author post (linked from the article), people are reporting PDF X-Change as ignoring that part of the language spec and not executing the payload.

    I haven't tested if that's true.

  4. Clever social engineering... by Chris+Burke · · Score: 2, Interesting

    You open the .pdf. On page 1 you see: "Hey you! Close this file, rename it to end with '.exe', and then double click it! There's, uh, boobs! Yeah lots of boobies."

    Okay so that's not entirely accurate, and at least one .pdf reader requires no social engineering at all other than getting them to open the pdf itself. Why would you make it so that you can't (normally) embed executables in the .pdf, but then allow .pdfs to launch arbitrary commands?

    --

    The enemies of Democracy are
  5. Re:PDF-XChange by the_humeister · · Score: 2, Interesting

    Each of us is composed of trillions of eukaryotic cells and even more bacterial cells. Thus, we think it appropriate to use "we" when speaking for us.

  6. *nix vulnerable too? by cpuh0g · · Score: 3, Interesting

    What happens on *nix versions of Adobe Reader - OS/X, Solaris, Linux, etc?

    1. Re:*nix vulnerable too? by Onymous+Coward · · Score: 3, Interesting

      /OpenAction <<
         /F <<
           /DOS (C:\\\\WINDOWS\\\\system32\\\\calc.exe)
           /Unix (/usr/X11R6/bin/xcalc)
           /Mac (/Applications/Calculator.app)
           /TheAnswerIs (yeah\\\\i/think\\\\so)
         >>
         /S /Launch
      >>

  7. Yup, part of the PDF spec by MagicM · · Score: 2, Interesting

    If you're really a nerd, you'll want to scroll through the PDF Reference section 8.5 ("Actions"). Be careful though, as it may hurt a little.

    Instead of simply jumping to a destination in the document, an annotation or outline item can specify an action (PDF 1.1) for the viewer application to perform, such as launching an application, playing a sound, or changing an annotation's appearance state. [...] In addition, the optional OpenAction entry in a document's catalog (Section 3.6.1, "Document Catalog") may specify an action to be performed when the document is opened.

    It's actually very well-defined, and creating a document that implements this part of the specification should be trivial.

  8. Management breakdown at Adobe? by Futurepower(R) · · Score: 2, Interesting

    "... competition going on in Adobe to see if the Flash or Acrobat teams can collect the most security advisories?"

    There seems to be a social breakdown at Adobe. There are a lot of issues that aren't being managed well. For example, we bought Adobe Creative Suite 3 (before CS4 was released). The CD had an old version. To get the newest version it was necessary to download a 320 Megabyte file, on the same week that Adobe shipped the CD.

    The new Acrobat takes longer to make .PDF files than the older versions. When we talked to people at Adobe about that, we got evasive replies.

  9. Re:Sad by Darinbob · · Score: 2, Interesting

    I'm behind the times. Isn't the PDF format a document format, that contains only document markup and layout info? When did it start being able to have embedded code? I know it's massively changed since I last looked at internal, with things like permissions and editing added, but executables or scripting seems a bit far fetched. Maybe we need a document format that involves nothing at all except documents...

  10. Re:A better test file. by Anonymous Coward · · Score: 1, Interesting

    Win XP, Firefox 3.6 Adobe 9.1

    Document opens fine in a Firefox tab, but no popup.

    I checked my settings (Page Display Preferences > Trust Manager).

    I do not have the box checked that says "Allow opening of non-PDF file attachments with external applications".

    You shouldn't either.

  11. Re:further proof D. Knuth was right by pclminion · · Score: 3, Interesting

    PDF has some superficial syntactic similarities to PostScript. Beyond that, it is not at all like PostScript. The reason the content stream language of PDF is PostScript-like is because it made it easy to print PDF by simply blowing the content stream out as PostScript, accompanied by the appropriate ProcSets. Such usage is deprecated these days -- ProcSets are no longer required to be declared, and modern PDFs can't be printed by blowing the content stream directly to the printer any more.

    Even in the areas where PDF looks like PostScript, it's fundamentally different. There is no operand stack. There are no control flow operators. If you start trying to create a PDF under the impression that it's just like PostScript, you'll fail miserably.

  12. Re:PDF-XChange by Anonymous Coward · · Score: 1, Interesting

    The two major pdf readers on linux (okular and evince) are not vulnerable however....

    They decided not to support silly things in the spec.

  13. Obligatory Adobe Story by bmajik · · Score: 2, Interesting

    So I work for Microsoft.. most hated software company, right?

    Not always, apparently. Thanks to competition like Adobe, we're going to have to up our game.

    Without going into too many details, a friend of mine was a Microsoft developer that was in a position where he was trading email with an extenal ISV as part of a formal MS program. So there was this stream of question and answer emails between them about how to use what we were working on to address this ISV's particular business problems. Anyway, at the end of one of this ISV's emails back to us, he says

    "PS: Can you guys somehow crush Adobe Corporation? I honesly and truly hate them."

    So there you go. That day, we lost. Adobe was the more hated company. We resolved to work harder to be #1 again.

    --
    My opinions are my own, and do not necessarily represent those of my employer.
  14. Re:PDF-XChange by 99BottlesOfBeerInMyF · · Score: 2, Interesting

    While details are hard to come by I think this may run deeper than pdf.

    Clearly security issues go beyond this single flaw in PDF and to some of the primary assumptions of OS's in mainstream computing.

    The whole idea of "opening a file in a way determined by the OS for that type of file" is poor from a security point of view.

    I disagree. That is to say, can't think of any better way. The OS determining what to use makes for a smaller exposure to exploitation because an attacker cannot specify or know what will be used to open a particular data type in most instances.

    Opening a file can mean anything from viewing an image in an image viewer (safe unless there is a bug in the image viewer) through opening something like an office document (may or may not be safe depending on office security settings) though to running an executable (unsafe by design).

    You provide three examples, but all three could be made quite safe if OS's were designed to do that. Sandbox every application and give it access to only what it needs. Monitor the integrity of the sandbox. In my opinion an average user should be able to run a random .exe file from an unknown, untrusted source and the OS should appropriately restrict that executable to prevent harm. That's not to say the user should not be able to override the OS's decision, but only when made aware of exactly what the executable is trying to do and being given the choice of doing it in a safe environment instead.

    Heck, I can do it today. Send me a random .exe file and I can put it into one of my premade windows VMs, run it, only granting explicit access to my real data as needed, and reverting the VM back to it's original state or saving it as a one-off for using that executable. The problem is, this task is far too difficult for the normal user. The whole process could be streamlined and automatic though, if the market was responsive to the needs of users.