Slashdot Mirror
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."
This vulnerability is not inherent to PDF but to Adobe's implementations.
Use Foxit! Reader on Windows and something else on other operating systems, such as Okular.
...Steve
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?
I want to delete my account but Slashdot doesn't allow it.
does it affect other platforms as well. Or is it Windows specific?
Yes and no respectively. It only affects Adobe Reader. All other PDF software is unaffected, I believe.
I can't believe you don't know what a Hasemalphaginnojinglanaporphomism is.
Black hats don't read slashdot to fish for new exploits.
Don't quote me on this.
If you allowed a popup to occur you were not being careful.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.)
So when I click once on a file, executable code is run from the program associated with that file?
When I view a file in Thumbnail mode, executable code is run from the program associated with that file?
When I hover to get a filename, executable code is run from the program associated with that file?
How many other daft, unnecessary executions of programs are there?
Not surprising because this is Windows we are talking about but holy crap - what a way to design a file browser / operating system. The problem here is NOT Adobe, or PDF or anything else, the problem is terminally-shit operating system and file browser design - executing entire programs to perform unnecessary tasks (e.g. add a column to explorer, generate a small bitmap, provide some hover-text). My next question is: in which user context is that code run? Please tell me that it is AT MOST the current user and not SYSTEM or some other built-in account. This sort of stuff should be found by a series of regexp's (which the program supplies) on the file data, NOT letting the program run just to tell you that Fred wrote this particular file. Then you can execute those to your heart's content in a secured area that benefits from global security upgrades if anyone finds a way to compromise the regexp. A bit like using "file" on *nix... just supply it with a regexp for a particular file extension and let the regexp extract the date, time, author, etc. in a safe environment.
No. Not MS. Every bit of freeware, every crappy game, anything that associates itself with a filename (which is almost impossible to stop on a home PC, only possible to detect/undo if you know how) is constantly run everything you view explorer in Thumbnail mode, or hover, or click on a file.
It reminds me of a little bit of trickery I did back in school... given the task to "hack the school network" on a computer course, we managed it within minutes by running exploit programs. Being the brightest IT student back then, I was asked to help prevent a repeat... my solution was to misuse the Windows 3.1 file associations in the global WIN.INI so that .exe, .com, .bat, .pif were associated with a tiny program that everyone had network access to. Anytime anyone ran a program, it was sent as a command-line parameter to this "security program" instead.
From there, the *program* would decide if the requested executable was actually valid and allowed (i.e. correct path, correct hash, put there by the network staff etc.) and if so, it executed it. If not, it popped up a message to deny access. It was surprisingly secure, given the state of multi-user networked Windows 3.1 back then, and even from an Administrator account we found it virtually impossible to get around provided other, more ordinary security was in place on WIN.INI (we even had to reset the admin account once because it managed to lock us out when we misconfigured it... fortunately, we had spare, unaffected accounts because we couldn't find any practical way around it!). Back then, though, you had to double-click, or File... Run... or whatever to make a program execute from the Windows shell... it even caught program execution from within Word macros that the network manager had been fighting for months ("A=Shell("Z:\game.exe")")... though not from a DOS shell, IIRC but we already had DOS Shells disabled by preventing the command.com from running except in specific contexts!
How easy it would be to write a piece of malicious code that associated itself with all executable file types and executed BEFORE the executable... so even when you try to run Remove_Sasser.exe or Install_Antivirus.exe, it would be intercepting and denying those requests. Obviously this has always been possible to do when somebody double-clicked on a executable, but now the associated program gets run just by LOOKING at any file with the right filetype. Make that executable a self-replicating virus and it's basically unstoppable (Yes, if you're
My Adobe PDF is loading. I'll let you know if it's safe or not in about 5 minutes
"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'.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
Does it matter? GP could also have have been tricked to click a link that leads to the same page as the popup. Disallowing popups would not have saved him in that situation. The problem is not allowing popups, the problem is that his browser was not secure.
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..
Colorless green Cthulhu waits dreaming furiously.
Why in the world was this marked "Informative"??
The three exploits that Didier shows in his blog do NOT use javascript!!!
This "fix" won't work with these exploits.
Not '+1 Informative', this should be '+1 Misleading'. Disabling javascript is *not* sufficient to protect you against this exploit.
"If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
Not correct.
As to JavaScript, itâ(TM)s possible to exploit the /JBIG2Decode vulnerability without using JavaScript, and there are samples of this found in the wild.
—here.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Right now I have to use Adobe Acrobat Professional, because I have a TabletPC, and need from time to time to highlight, or annotate, PDFs. Do you know a better alternative? Thanks a lot
How is a microkernel going to protect against a phenomenon that happens completely within userland?
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).
Can I assume that you're upset about HTML having all this stupid Javascript stuff, too?
I can't speak for the original poster, but I'm certainly happier since I installed the NoScript extension in Firefox. Slashdot was one of the main reasons that I installed it, as there was some script on the front page that used to freeze my browser for a few seconds for no good reason.
In a PDF "document" I sure as hell don't want any active scripts beyond the ones that are needed to generate the pixels I'm looking at. I can see a use for interactive forms and similar scripted things, but they should not be lumped into the same category as read-only documents.
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.
Digital Citizen