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.
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.
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
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.
'You can read the source' is irrelevant 99% of the time;
The point is that someone, other than the original author, can and most likely has.
Paying taxes to buy civilization is like paying a hooker to buy love.