PDFs Exploitable?!? I’m shocked…

September 2009 saw some key security analysis raining directly onto the Adobe PDF platform, particularly with SANS pointing towards remote code execution within PDFs as one of the top threat vectors:

  • Adobe Acrobat, Reader, and Flash Player Remote Code Execution Vulnerability (CVE-2009-1862)
  • Adobe Reader Remote Code Execution Vulnerability (CVE-2009-1493)

Kudos to Adobe for patching these security holes. What happens when flawed functionality of Acrobat PDF file format leaves the door wide open…?

    • “Researcher Didier Stevens [created] a proof-of-concept PDF file showing how an executable file can be launched directly from Adobe Reader or FoxIt without the use of an actual software vulnerability.”

Imagine: Autorun flaws now for your Adobe Acrobat PDFs

In plain language, if you click on the PDF you launch both the PDF and an embedded executable script or program. Like anything else, this is bad and good depending on intent. This programming potential has been around for a long time so let me be clear: on the bad side we’re talking about social engineering a functionality to do something the PDF is  not supposed to do: get a user to click and launch external code.

Additionally, unconfirmed research by Jeremy Conway displays the potential for a PDF worm making the vector rapidly scalable across anyone’s network. Jeremy sums up the threat:

    • Worse yet this dynamic infection vector could be utilized to populate all PDFs for some new [zero-day] attack, thereby multiplying an attackers infection vehicles while still exploiting user systems (“worm-able”).  This should really make you think twice even before you open up PDF files that have resided on your computer for years, as they could soon be the utilized against you if an attacker chose to do so.

How the exploit works:

  1. According to the researcher Didier Stevens, the exploit is really very simple: it uses the /launch /action to execute any arbitrary .exe file embedded into the PDF.
  2. With Foxit it would simply launch the embedded executable.
  3. With the Adobe Acrobat Reader it’s social engineering telling the user to ‘click me’ after displaying a modified message instruct ing the user to launch the offending application. The ‘phished user’ clicks thereby launching the embedded executable.

Speaking of embedding PDF executables, that’s a somewhat sophisticated step in itself. I’m not saying it can’t be done, in fact Didier has a method detailed here, but my resources relay that it’s somewhat tricky. 

With great power comes great responsibility

Although this issue affects a large percentage of the PDF-using public, according to Gregg Keizer’s article for ComputerWorld, the Adobe response can be interpreted to brush off the threat as someone else’s problem:

    • "Stevens' demo relies on functionality defined in the PDF specification," Adobe said. "This is an example of powerful functionality relied on by some users that also carries potential risks when used incorrectly. The warning message provided in Adobe Reader and Adobe Acrobat includes strong wording advising users to only open and execute the file if it comes from a trusted source."

Foxit however has posted a security bulletin detailing their timeline in responding with an updated version of their browser – particularly helpful since launching with Foxit previously would not bring up any user prompt intercepting the code execution.

Gentle Disclaimer:

In the past few years I’ve done some not-so-gentle research into Adobe’s Corporate Authenticity. I share frustrations with the researcher and with Gregg Keizer’s interview regarding the ability Adobe has in answering about specifics. I did quite a bit of blogging about issues in transparency which Adobe had a few years back with another product, which now may or may not have been corrected.

My own personal struggles with corporate authenticity at Adobe were unfulfilled as well. I have done significant research into the SEC filings of Adobe and happen to have some solid stock price predictions as past analysis.

Why didn’t he tell Adobe first?

I can sympathize with the researcher creating a proof of concept before attempting to contact Adobe because Adobe’s history in proactively fixing PDF vulnerabilities is anything but exemplary:

    • In 2009, Adobe patched four PDF vulnerabilities only after they had already been exploited; 2010 hasn't started out much better, with one PDF zero-day already on the books.

For serious researchers, I highly recommend checking out the author’s site comments where, as you can see from this screenshot, the latest posts have already become ‘viral’:

Comments from Didier's site

Question: What exactly will the response be…?

  1. Foxit has taken the high road in regards to security flaws and posted them on their website. “Warts and all…” Time will tell if their modification actually blocks enough functionality to be a concern for their clients.
  2. Other PDF readers could disable the functionality completely (perhaps using Didier Stevens’ developed method) or bide their time, waiting on Adobe.
  3. To get an idea of the scalable PDF network threat, read Jeremy Conway’s blog article found here.

Patches are due out April 13th for the Adobe Acrobat Reader. It remains to be seen whether this /launch /action trickery will be addressed within the Reader itself or left alone as Adobe has previously stated.

Contributing Writer, Securing Our eCity

Author , ESET

  • ESET

    Update that released a few hours later from ZDNet:

    Update April 6 9:15 a.m. PDT: An Adobe spokeswoman replied Monday night with the same statement above and this: "Users can also turn off this functionality in the Adobe Reader and Adobe Acrobat Preferences by selecting > Edit > Preferences > Categories > Trust Manager > PDF File Attachments and clearing the box 'Allow opening of non-PDF file attachments with external applications.'"

  • ESET

    Here's another update:
    From blogs.adobe.com/adobereader/ comes this IT-focused solution which can be pushed out to protect an entire company:
    ——forward to your IT group—–
    For administrators who wish to accomplish this with a registry setting on Windows, add the following DWORD value to:
    HKEY_CURRENT_USERSoftwareAdobeAcrobat Reader9.0Originals
    Name: bAllowOpenFile
    Type: REG_DWORD
    Data: 0
    Furthermore, an administrator can grey out the preference to keep end-users from turning this capability on, by adding the following DWORD value to: HKEY_CURRENT_USERSoftwareAdobeAcrobat Reader9.0Originals
    Name: bSecureOpenFile
    Type: REG_DWORD
    Data: 1
    Note: These samples assumed you were adding registry settings to Adobe Reader 9. For Adobe Acrobat, you would replace "Acrobat Reader" with "Adobe Acrobat", and for a different version, you would substitute its value for "9.0".

Follow us

Copyright © 2017 ESET, All Rights Reserved.