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.
Since PDF is Portable, does it affect other platforms as well. Or is it Windows specific? Does it affect other libraries than the Adobe ones? And why the fsck does a freakin' DOCUMENT have scripting in it? I can understand form elements but not something akin to shell scripting.
Custom electronics and digital signage for your business: www.evcircuits.com
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.
I caught my first ever virus using Firefox thanks to some sort of PDF exploit. Was browsing normally, got a popup that flashed up for a brief second and I saw it was a PDF of sorts. My hdd started thrashing and my anti-virus started giving me dozens of warnings.
Managed to make sure there was no trace of the virus on my system but it serves as a warning to people who assume Firefox is perfectly safe providing you are careful.
Black hats don't read slashdot to fish for new exploits.
Don't quote me on this.
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.)
Dearest Joey
I have finally managed to make it display knitting patterns, so I updated the master source on sourceforge.
All my love,
Granny
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
article pointed me to [HKEY_CLASSES_ROOT\Folder\shellex\ColumnHandlers\{F9DB5320-233E-11D1-9F84-707F02C10627}] @="PDF Column Info"
Hoping to mitigate the vulnerability, I deleted the key after exporting it. However it does not cure the idiocy of Adobe allowing executables in something supposed to simply describe a document.
Enlightenment? It's just a flush in the pan.
My Adobe PDF is loading. I'll let you know if it's safe or not in about 5 minutes
One thing I can add is that we have seen far worse examples of direct attempts at subverting and compromising user/consumer computer systems with their software products in the past. If we have seen worse, it's a lot less unreasonable to guess that this sort of thing is intentional.
Adobe PDF needs to be shunned in favor of open implementations just as MSIE is slowly being shunned in favor of Firefox.
The problems is caused by a buffer overflow error in the program, which allows arbitrary code execution
IMHO this is the real problem behind today's security problems on popular platforms: the quick progression from [simple programming error] to [malicious code can do whatever it wants].
Perhaps a better solution would be to move to microkernel-based operating systems. These have a natural tendency to confine breakage to a small area. In contrast to popular systems, that behave more like a water balloon. Microkernels may have had a bad reputation in the past (slow performance), but nowadays that is neither true (see L4 for example), or relevant anymore (with GHz. machines being the norm). Reliable & secure software is what matters now.
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.
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.
"How to Do Nothing," kids activities, back in print!
Isn't Foxit free (as in beer) though?
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).
As always, Foxit does all that stuff.
Insert typical: it's also smaller, more efficient, free* and typically immune to these types of attacks.
* Sure, theres a "pay" version, but the only thing I've ever noticed is when you add text to a pdf it puts a little "Edited using Foxit!" stamp on the top of the page. A small concession IMO.
Sex. Drugs, and Unix.
I know, I know, I just replied to myself, bad form. But I probably should've linked to the site for Foxit. Here's the download page.
But ya, worth a try at least, it is free.
Sex. Drugs, and Unix.
If they infect enough machines, perhaps something will finally be done about it.
---- Booth was a patriot ----
As all companies in this economic disaster you will layoff people. I am sure you know which department to layoff and while on it, don't forget the OS X guys which manages to keep Debugger() symbols in World's most popular plugin, Flash.
Yes OS X people and especially Webkit/Browser developers, that mysterious ''Debugger() was called!'' in system.log comes from Flash 10 plugin because idiots forgot to remove debug symbols! That is a bug which wasn't fixed for months and even in recent security update release of Flash wasn't used to fix it.
Look to description: http://www.stinkbot.com/blog/archives/69
We will end up with Silverlight and Document XPS or something from MS as result, that is what drives me nuts. We live same junk which almost made MS Wmedia standard in 1990s. History repeats itself.
It was originally Javascript thing which could be fixed just by disabling javascript.
I think the person you replied to has good intentions and can't imagine the issue is that bad and fscking Adobe still wonders around without patching it.
If it was a government created such a security issue for a country, they would resign.
Considering that Adobe still hasn't fixed the broken thumbnails in 64-bit environments (as of Acrobat 9 with current updates), this exploit seems to affect 32-bit systems. I haven't yet seen working .pdf thumbnails in 64-bit Vista (or Windows 7 Beta, for that matter).
Jarnal. It's a bit obtuse (you'll need to remove the default lined background, then open the PDF you're annotating as a background image – which does mean you can't edit the text, unfortunately), but then, it is free. It's done what I wanted, more or less.
If all you want to do is highlight (there are several pen tools which can be used to highlight or draw) or annotate (there's also a text tool, which as I mentioned can't edit the existing text in the PDF), it'll probably be adequate.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
E-Copy.
It is not free, but it is an excellent work-flow tool (that uses PDF as the framework).
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
How is a microkernel going to protect against a phenomenon that happens completely within userland?
To all of those who don't think they want to see "executable code" in a PDF document....
How else would you implement a typesetting language? There is a big problem with simple bitmapped fonts, they don't scale, no sharp edges unless the scale of the bitmap exactly matches the screen resolution. So we need __instructions__ on how to draw the characters. Also those instructions change if the characters is large or small relative to the screen resolution. You can't make goos looking documents without some kind of interpreter. All good typesetters are interpreter.
That said you COULD make a safe interpreter by limiting what it has access to.
By making practically everything into userland, including hardware drivers, filesystems, GUI's, etc. In most OS'es that's a lot of code, and there are bugs and vulnerabilities in there too, you know.
Maybe so, but not relevant to the original topic which was buffer overflows in user applications.
By enforcing strict limitations on what each part can do. In a common OS, malicious code can do everything a normal user can do. In a microkernel OS, that part may have no disk access rights whatsover, and only permission to communicate with a small number of other components. Such restrictions can be enforced strongly, and everywhere throughout the system. That makes breakage much more a local event, with limited damage.
That doesn't really have anything to do with the kernel architecture. You're talking about a capabilites-based system, and/or splitting user apps into groups of sandboxed subprocesses, both of which can be done with or without a micorkernel. What you want requires rewriting all end-user applications from scratch, but it could be done with only minor modifications to standard kernels.
Even Microsoft was able to introduce a limited form of that concept into Vista with their low-privileged IE sandbox.
It's even more damaging as microkernel servers are run in userspace too.
Here be signatures
I can't seep to find this 'Windows Explorer Shell' thing in aptitude or synaptic.
Apparently it's a buffer overflow condition and it doesn't require scripting to cause it.
Solution:
1. If you haven't already, stop using IE. Use Firefox. (IE opens PDFs automatically and AFAIK there's no way to prevent this.)
2. Disable the Adobe Reader plugin for Firefox (Tools, Add-ons, Plugins, Adobe Acrobat, Disable) so it won't open PDFs in the browser. Do not specify to open them with Adobe Reader by default, obviously.
3. Disable the Adobe shell extension (http://www.nirsoft.net/utils/shexview.html is apparently the best way to do that) to prevent the no-click exploit.
4. Don't open PDFs if they come from untrusted sources. If the shell extension is disabled, even if you download a malicious PDF, it won't be able to run its payload – unless you open it.
Or, uninstall Acrobat Reader entirely and use something else.
I'm pretty sure the no-click exploit in Explorer also wouldn't work if you close the "Details" panel, turn off file tooltips, and turn off the Status bar. I'd personally go the safe route and just disable the shell extension, though.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Please tag either linux AND windows OR windows AND 0Sx, or whatever- thanks.
you don't run the universe.
I haven't had any issues yet but then again I'm running Fedora 4.
..." comments. ...
It looks like a troll, but there are loads of "linux is fine" and "windows is ok if
Fedora 4 using Xpdf or Gpdf is fine as far as I can tell. But then I don't expect to run a program when I open a document. If you need help just ask, really
Is this a windows targeted vulnerability , yet again ?
I would have thought by now, that M$ would have noticed and fixed the issues so as not to be in the news so much. It's only been 15 years!
My Windows machine isn't capable of opening PDF files because Adobe Reader is bloated shit and I'm certainly not going to reconsider not after these events.
The million dollar question, If I do NOT use Internet Explorer and I do NOT use Adobe Reader (or any software product that uses Adobes PDF implementation, thus allowing the problems to occur), will I still have this problem or not? (Perhaps someone could post the link to an example corrupted file on one of the security websites so that we can test it with the browser we use)
If you are a web developer, make an alternative PDF formatted file available, if that even makes sense to do. Can you implement the PDF standard without implementing this feature that Adobe has added and Internet Explorer will NOT let you prevent?
For the open source developers who are developing PDF solutions, this might be a feature best NOT to implement, what do you think? As any software that implements this feature (which is really NOT necessary) is inferior by design.
Personally I would prefer that no solution that introduces proprietary bloat (whether registry BS, additional memory, additional resource usage on your system, active-anything that-I-can-not-turn-off, etc...) as most likely an open source alternative exists. And if it does not exist, creating an open source alternative that uses less memory, less system resources would be superior anyway.
Is your Internet Throttled? Install DD-Wrt, OpenWRT or Tomato to learn the truth! Google: 1Gbps/1Gbps: 5 Communities
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