PDF Vulnerability Now Exploitable With No Clicking

SkiifGeek writes "With Adobe's patch for the current PDF vulnerability still some time away, news has emerged of more techniques that are available to exploit the vulnerability, this time without needing the victim to actually open a malicious file. Instead, the methods make use of a Windows Explorer Shell Extension that is installed alongside Adobe Reader, and which will trigger the exploitable code when the file is interacted with in Windows Explorer. Methods have been demonstrated of successful exploitation with a single click, with thumbnail view, and with merely hovering the mouse cursor over the affected file. There are many ways that exploits targeting the JBIG2 vulnerability could be hidden inside a PDF file, and it seems that the reliability of detection for these varying methods is spotty, at best."

Comments

Not PDF vulnerability ... Adobe vulnerability

[forand]

This vulnerability is not inherent to PDF but to Adobe's implementations.

Re:Not PDF vulnerability ... Adobe vulnerability

[BrokenHalo]

Essentially I just want to read text and view images.

That's all PDF is for. I've lost count of the number of hours I've spent on the phone to users who imagine that editing PDFs with Acrobat Professional is going to be easy. The whole point of PDF is that it is an end-point document, viewable on screen or printable with a consistent format. It was never intended to provide a format designed for being edited.

That's where OpenOffice (or NeoOffice) has it right - providing a nice handy button to click to export your document as a PDF, but not leaving you under any illusion that that has anything to do with the real document.

DONT CROSS THE STREAMS

[Gothmolly]

Executable code should not be embedded in documents, the format should not allow it, and document readers should not execute code.

How fscking hard is this?

Non-install alternative for Windows

[Morris Thorpe]

I stopped using Reader long ago - not because of vulnerabilities, but because it was so slow and bloated and it installed stuff I did not want.

I've been using Sumatra for a very long time and it has done well by me (http://blog.kowalczyk.info/software/sumatrapdf/index.html)
Download the zip file for a no-install, single-file exe. Minimalistic but more than enough for 90 percent of pdf's I ever need to open (the rest, I open through Google docs.)

Why all the paranoia about executable code

[gzipped_tar]

One thing I don't understand is the seemingly common paranoia towards "executable code" in the discussions here.

First, there's no fundamental difference between "code" and "data". It's all binary blob. The .text section in any of your ELF programs is understood as "executable code" by the interpreter (ld.so) but as plain document by objdump. The point is to always interpret the data as how it is intended to be used, and this is hard. This Adobe fiasco is caused by a buffer overflow in the program (which is not even in a function responsible for JavaScript). Buffer overflows are known to be useful for exploits because they allow an attacker to "cheat" the program so that it misinterprets what intended to be document data as executable code. It just happens that the flawed code can be attacked with greater rate of success using JavaScript. (According to this security advisory http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219)

Second, embedding executable code in a document is not inherently evil or stupid. It's just an idea that can be either utilized or abused, varying from implementation to implementation. I don't like scripting in PDF either but not for the reason of its alleged insecure nature, but because it bloats the file format.

Just my 2c..

Code = OK, connect to outside = bad!

[jonaskoelker]

Executable code should not be embedded in documents

Why not? Seriously, why not?

The real problem, IMNSHO, is not that there's code, but that the code is allowed to do other things than to just compute stuff.

I'm not really sure why you'd want documents to contain code, but I can imagine someone might want to say "the first 20 primes are 2, 3, ..." and have the computation done at "run"-time. Or at least, something else interesting that exceeds the capabilities of easily analyzable language classes (regular, context-free).

The badness happens when document-embedded code can read my file system, write to my file system, run other programs that are outside its own sandbox, or talk to others via the network.

(I think the Java security model tried to do approximately this.)

As a way to attack parts of the problem, perhaps document readers should just run the format interpretation code in a process which drops all unnecessary capabilities?

At least in principle, being able to compute doesn't mean being able to violate your security concerns.

In haskell terms, none of the code inside a document should have the type `IO a', and then you'd be safe (assuming of course that unsafePerformIO and the like didn't exist).