PDF Vulnerability Now Exploitable With No Clicking 206
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."
Not PDF vulnerability ... Adobe vulnerability (Score:5, Insightful)
DONT CROSS THE STREAMS (Score:4, Insightful)
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?
Re:Getting it out there (Score:3, Insightful)
Black hats don't read slashdot to fish for new exploits.
Non-install alternative for Windows (Score:5, Insightful)
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.)
Re:DONT CROSS THE STREAMS (Score:1, Insightful)
Basically there's no difference between executable code and non-executable data by nature. The problems is caused by a buffer overflow error in the program, which allows arbitrary code execution, bypassing the usual, intended input validation (if any).
So, this has nothing to do with the document format standard. Even if the standard forbids executable code (whatever that means), a coding error could render this kind of protection futile.
Re:Does it affect other platforms as well? (Score:3, Insightful)
"And why the fsck does a freakin' DOCUMENT have scripting in it? I can understand form elements but not something akin to shell scripting."
Can I assume that you're upset about HTML having all this stupid Javascript stuff, too? I mean, it's just for displaying and linking to information. It doesn't need 'something akin to shell scripting'.
Why all the paranoia about executable code (Score:4, Insightful)
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 [shadowserver.org])
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..
Re:Not PDF vulnerability ... Adobe vulnerability (Score:3, Insightful)
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.
Re:Buffer overflow - arbitrary code execution? Why (Score:3, Insightful)
How is a microkernel going to protect against a phenomenon that happens completely within userland?
Code = OK, connect to outside = bad! (Score:4, Insightful)
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).
Re:Curse you, von Neumann! (Score:1, Insightful)
I just don't get it. What exactly is so difficult about the concept of a file format containing data only, that is passively rendered by an application?
The post directly above this post [slashdot.org] responds so nicely to your post that I wanted to make sure you saw it.
Re:Not PDF vulnerability ... Adobe vulnerability (Score:3, Insightful)
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 problem is that people do not understand the difference between a text editor or word processor and a print layout or typesetting program. Acrobat is more like the latter and less like the former. If people understood a bit more about the different goals of these different programs then they would not be as surprised that it isn't easy to use a professional print layout tool just like they would use a word processor.
Adobe Reader is just the latest example. (Score:3, Insightful)
I'll bet you're right: there's simply too much source code in a modern-day free software OS for any one user to inspect it all, much less change it to suit their needs. But to jump from this perfectly reasonable conclusion to rejecting the freedoms of free software is illogical, ignores the lessons of history, and is therefore most unwise.
You're always better off with the freedoms of free software even if you don't leverage all of those freedoms yourself. This is one of the great differences between the "free software" movement and the "open source" movement: software freedom (what open source was designed to not talk about) is a good unto itself. I don't buy that the advantages of the open source development methodology are as uniform as I'd like because I know of plenty of programs licensed under OSI-approved licenses which are inferior to their proprietary alternatives or are simply poorly written in a way you can see without comparing to any other program. Instead I choose the software that respects my software freedom, even if it's not the most reliable or powerful, because I know if I need to inspect or improve that program myself, hire someone else to help me, or ask for help from the community I have the permission to do that. Proprietary software takes those possibilities off the table and leaves me to negotiate with a monopolist. Some proprietary software even denies me the freedom to run the program.
I'm not interested in "OSS" and I've demonstrated my willingness to pay money for my software freedom if need be (unlike some who want free-as-in-cost software, I'm for commercial software development and distribution). I'm interested in the freedom which lets me control my computer to the limits of my efforts, and the freedom to share any improvements I want to share (even commercially). I'm interested in building and defending the community that comes from valuing software freedom for its own sake, so I'm a free software activist.