Google Employees Find 60 Security Holes In Adobe Reader

sl4shd0rk writes "Upon examining the PDF Engine behind Google Chrome, Google employees Mateusz Jurczyk and Gynvael Coldwind discovered numerous holes. This led them to also test Adobe Reader, which turned up around 60 holes which could crash the PDF reader, 40 of them being potential attack vectors. The duo notified Adobe, who promised fixes, but as of the latest updates (Tuesday of this week) for Windows and Macintosh, 16 of the reported flaws are still present (the Linux version has been ignored). To prove it, Mateusz and Gynvael obfuscated the info and released it, saying the unpatched holes could easily be found. The Google employees therefore recommend that users refrain from opening any PDF documents from external sources in Adobe Reader."

Comments

PDFs

[girlintraining]

PDFs have been a security headache for decades now. It originally started as an evolution of PostScript, but has since morphed into a "document solution". Adobe, like so many tech businesses, can't simply create a tool and then be finished. They always have to add more features, more code, more bloat. And surprise surprise, problems arise.

When I go to work on my car, I know my ratchets will work on any bolt on it; I just need to figure out what size it is and maybe an extender and I'm in business. My tools just work; they rarely break, and they don't stop working with next year's model... or the next decade's. Or the last. My ratchets will work on 1950s model cars, and I'm sure they'll still be useful on a 2050 model car.

Linux is more like my ratcheting set. Sed, awk, bash scripts... they don't change. They were there 5 years ago. They'll be there 5 years from now. They're simple, dependable, and "just work". What the fuck is so hard about making a read-only flat document that does the job of being easily readable and printable well? Stop adding features. Make the product do one thing well, and then use the profits to make a completely different product if you need something else done well.

Be like the ratchet.

Re:PDFs

[Eponymous Hero]

imho it got out of control when they added executable javascript.

Re:PDFs

[Meshach]

Stop adding features. Make the product do one thing well, and then use the profits to make a completely different product if you need something else done well.

Be like the ratchet.

That works for an open source project where the ultimate goal is to provide a usable product. If the project is already usable then do not add more features. Adobe though is a commercial product. They have to constantly change things and add new features so that their customers will need to upgrade to the latest version. This constant upgrading inevitably introduces instability.

Re:PDFs

[fm6]

Lots of products get "improvements" that are anything but. The point of making stuff is to sell it, and you can't sell new stuff unless you can convince folks that their old stuff is obsolete. You can see that any time you visit a car dealer.

Ratchet design isn't static because their makers woke up one day and said, "It's perfect! Let's stop trying to improve it!" They just don't have any design improvements that will convince you to throw out your old ratchets and buy new ones. If they could, they would.

Re:PDFs

[JDG1980]

Adobe Reader is freeware. Why would Adobe want their "customers" (who pay nothing for the software) to constantly upgrade to new versions?

Adobe Reader is a marketing tool used to sell upgrades to Acrobat. They want to be able to ship new features in new versions of Acrobat, and to do this, they consider it helpful to be able to ensure buyers that "everyone" will be able to use their new whiz-bang documents/forms/whatever.

Re:PDFs

[bcrowell]

Postscript - integral to PDF internals - is itself a Turing-complete language, derived from Forth.

It will always be a problem.

No, because PDF, unlike PS, was intentionally designed to be Turing-incomplete. That was a good design decision, which was then unfortunately screwed with when they added javascript.

How hard is it to find security holes in Adobe?

[Anonymous Coward]

I guess they just Googled it...

Re:Easy enough

[itsme1234]

30 EUR for a single license for "PDF-XChange Viewer" and you get only "1 year of product maintenance" (which probably means after one year you need to pay for security patches).
For a freaking pdf reader? And with no real assurance that this one isn't again full of security holes. Get real.

*Very* Sloppy Summary

[fm6]

The summary muddles two distinct PDF readers, the PDF reader built into the current version of Chrome (purely Google) and the PDF reader from Adobe that's completely separate. The Google reader is relevant only because the vulnerabilities in the Adobe reader were discovered using the tools developed to find vulnerabilities in Chrome.

Informed disclosure?

[bill_mcgonigle]

Google was irresponsible in not publishing these holes immediately so affected users could take steps to mitigate their vulnerability while Adobe put together a patch.

The Full Disclosure folks say that vulnerabilities should be disclose immediately. Their arguments have some merits. The Responsible Disclosure folks say that the vendor should have n number of weeks to get a patch out, then it goes to Full Disclosure. That has some merits as well, but the trouble is the public doesn't know there's a problem during the n weeks. The calculation is a balance of how many people will be protected vs. how many people will be harmed.

It occurs to me that a third way, call it 'Informed Disclosure' for now, would be to:

1. Make an announcement that x number of vulnerabilities have been discovered in the foo function of bar
2. Wait the n number of weeks
3. move to Full Disclosure

as a way to avoid the problem with Responsible Disclosure but still give the vendor reasonable time to react. e.g. 'Informed Disclosure' may say:

ISSUE-001: Acrobat Reader has a vulnerability with JavaScript objects embedded in documents that can cause a smashed stack. Disable JavaScript in Acrobat Reader to avoid this problem.

and then send Adobe the exploit code, which will be published in 45 days. This also removes the illusion of potential blackmail from security researchers, because the public has on-record information that the disclosure will be published, regardless of the action or inaction by the vendor.

Surely others have taken this approach, but I can't find a name attached to it -- anybody?