Adobe swings and misses as PDF abuse worsens

Summary:After more than two weeks (months?) of inexplicable silence on mitigations for a known code execution vulnerability in its Reader and Acrobat product lines, Adobe has finally posted public information on the problem but the company's response falls well short of providing definitive mitigation guidance for end users.

After more than two weeks (months?) of inexplicable silence on mitigations for a known code execution vulnerability in its Reader and Acrobat product lines, Adobe has finally posted public information on the problem but the company's response falls well short of providing definitive mitigation guidance for end users.

[ For background and a timeline on how *not* to handle incident response, HD Moore's blog post is a great start. ]

Adobe's response simply confirms what we already know and reiterates that turning off JavaScript will NOT eliminate the risk entirely.  However, the company does not offer any definitive suggestions or workarounds, instead pointing to a list of anti-malware vendors blocking known attacks.

Here's what we have from Adobe:

  • We have seen reports that disabling JavaScript in Adobe Reader and Acrobat can protect users from this issue. Disabling JavaScript provides protection against currently known attacks. However, the vulnerability is not in the scripting engine and, therefore, disabling JavaScript does not eliminate all risk. Keeping this in mind, should users choose to disable JavaScript, it can be accomplished following the instructions below:

  1. Launch Acrobat or Adobe Reader.
  2. Select Edit>Preferences
  3. Select the JavaScript Category
  4. Uncheck the ‘Enable Acrobat JavaScript’ option
  5. Click OK

While this information is better than the silence we've gotten from Adobe since the attacks became public, it falls well short of providing the protection information that businesses and end users need when in-the-wild malware attacks are occuring.

The company did not offer any details on the actual vulnerability.  It did not provide workarounds.  It did not provide mitigation guidance.   Adobe simply rehashed what we already knew and confirmed that the public mitigation guidance from third parties is/was not definitive.

As my former ZDNet Zero Day blog colleague Nate McFeters points out, the issue is much worse than first imagined.

  • I decided I'd test this out and found that on a fully patched Mac OS X build, Safari 4, Mail.app, Preview.app, and potentially others all crash using the proof of concept exploit provide on milw0rm.  The crash is actually in PDFKit, which supports all of those applications and likely much more.

According to this Secunia's Carsten Eiram,  his company managed to create a reliable, fully working exploit which does not use JavaScript and can therefore successfully compromise users, who may think they are safe because JavaScript support has been disabled.

  • All users of Adobe Reader/Acrobat should therefore show extreme caution when deciding which PDF files to open regardless of whether they have disabled JavaScript support or not.

If Secunia can do it based on information that's public, what's to stop malicious hackers with major financial motivation?

So what now Adobe?

Topics: Software Development, Enterprise Software, Open Source

About

Ryan Naraine is a journalist and social media enthusiast specializing in Internet and computer security issues. He is currently security evangelist at Kaspersky Lab, an anti-malware company with operations around the globe. He is taking a leadership role in developing the company's online community initiative around secure content managem... Full Bio

zdnet_core.socialButton.googleLabel Contact Disclosure

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.