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."
Re:DONT CROSS THE STREAMS (Score:4, Interesting)
Sorry, but you lost this fight a long time ago. Even emacs supports embedded executable code in documents.
And don't forget Postscritpt. And LaTeX.
At the ICFP08 conference, there was a student who'd written an autonomous (simulated) robot controller, in LaTeX.
Whoa (Score:5, Interesting)
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
Re:Not PDF vulnerability ... Adobe vulnerability (Score:5, Interesting)
It's kind of a flaw that is endemic to the commercial software development model. This is not to say that that model is useless or F/OSS doesn't have its own problems.
The root of the problem is how we "add value" to a piece of software. Since with F/OSS, software development has a service model, you mainly add value by adding services: documentation, support, consulting. You can't "add value" by adding features to the software, at least if you try to you only get paid once for doing so.
A proprietary software developer can get paid multiple times for adding a piece of value into the software. For software that is sold, this is driven by market segmentation. The least pernicious form of this is the ubiquitous "bronze/silver/gold" model where they try to maximize their return from cheapskates, pragmatists and spendthrifts respectively. If you are cheapskate who needs a feature in the "gold" edition, you're out of luck. In the worst case, it drives a bewildering proliferation of "products", as vendors try to find the division of features that maximizes their returns (which is an instance of the NP-Complete "integer programming problem", only approximations are practical). From a customers standpoint, it sometimes looks like a whirlwind has picked up all the features and dropped them into random pigeonholes.
The "value adding" imperative still applies to free as in free beer proprietary software. In such cases, the developer still is looking to get paid, only in different coin, e.g. control of formats and the market power that comes with it. Adobe benefits from PDF being a non-proprietary format because it encourages adoption, but it is risky because they wouldn't benefit if they did not control the dominant implementations of PDF technology. And they try very hard, I think, to have the best implementations, which leads to the old problem of adding value by adding features. The hope is that by adding features nobody has asked for, when those features are missing from a different implementation, that implementation will be seen as less complete and polished. I think this often works, but it leads to this kind of blowback siutation: security flaws introduced to users systems along with features the user never asked for.
Curse you, von Neumann! (Score:2, Interesting)
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?
In fact, wasn't passive rendering the whole reason from moving from PostScript to PDF?
Is it that hard to review code and make sure that the interpretation of the format doesn't trigger any conditional branches that cause execution of anything but fixed, static, read-only code within the application? It seems to me you could use a modified version of one of the development tools used for embedded firmware development to guarantee that that's the case.
Why are software writers so enamored of "extensible" schemes that depend on data being executed?
I can see how executing data might have seemed like a cool concept in 1997, but this is 2009 and I don't want or need books in which monsters are capable of leaping out of the illustrations and grabbing me by the throat.
Re:DONT CROSS THE STREAMS (Score:3, Interesting)
No, the fight was lost when we first decided to use ones and zeros to represent both code and data. There is simply no significant difference between the two. Indeed, you can't have data which does not alter the execution of code.
Do you know a good software for PDF highlighting? (Score:2, Interesting)
Re:Not PDF vulnerability ... Adobe vulnerability (Score:1, Interesting)
Re:Does it affect other platforms as well? (Score:3, Interesting)
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.
Re:Not PDF vulnerability ... Adobe vulnerability (Score:3, Interesting)
It's really stupid that IE doesn't let you manage its behaviour when downloading a PDF.
Inside Adobe Reader (version 8 at least) under Edit|Preferences|Internet uncheck "Display PDF in browser" in the "Web Browser Options" group.
I'm seeing Preferences under Edit, not Tools.
Unfortunately, it still launches the PDF in Adobe Reader. That's no fix at all: malicious PDFs will still be opened automatically. There's apparently no way to have it prompt you to find out if you want to open, download, or not.