Google Employees Find 60 Security Holes In Adobe Reader 164
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."
Re:Easy enough (Score:2, Informative)
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.
The 30EUR product is their Pro version (more like Adobe Acrobat Standard), they also have a free version which does everything Adobe Reader does and more.
Re:Easy enough (Score:3, Informative)
Ahem
It's got commenting features without watermarking and even does OCR which I have been very impressed by.
Re:Alternative readers? (Score:4, Informative)
Re:PDFs (Score:5, Informative)
Postscript - integral to PDF internals - is itself a Turing-complete language, derived from Forth.
It will always be a problem.
Re:PDFs (Score:2, Informative)
That's true, but PDF is a subset of Postscript rather than a generalized programming language. For example, the control structures are removed (if, loops, etc.) It should have been possible to put many more limitations on it. Instead, they added back even more ways to shoot yourself in the foot (e.g., Javascript). That's just nuts, and explains why Adobe Reader has been a bloated, ever-expanding program since... well, forever.
What they need is a "Lean PDF" that is strictly limited to describing the page content, with no internal programmability. It would make for simpler parsers that can be checked more easily for security flaws. The "kitchen sink" approach of the current PDF standard makes it fiendishly difficult to support without leaving opportunities for all sorts of mischief.