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
Why aren't stories of this nature ever tagged 'Streisand effect'? Surely drawing attention to the wider blackhat doesn't help? Then again, keeping it quiet probably doesn't either... So who is doing the cost/benefit analysis of broadcasting this sort of info?
...already exists for this threat. People will learn, and mod this down at your peril.
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.
PDFs are a crappy format, Adobe Reader sucks. It's slow and bugs you repeatedly about updates.
Personally, I prefer using Preview (it's a program on Mac OS X) to view PDFs. It's a lot faster and the interface is much better.
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
If you're like me and have full Adobe Acrobat installed (Sumatra doesn't fill your needs and you don't own Foxit), there's a very easy way to workaround this security hole until it is fixed. Go to the edit->preferences menu, go to "Javascript" in the menu and uncheck the box that says "Disable Javascript in Adobe"
This should workaround the problem sufficiently until Adobe releases a patch.
More information here:
http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219
-=Lothsahn=-
I get alternately frustrated and paranoid about these sorts of things. How on earth can a DOCUMENT format have an exploitable code problem. How stupid do you have to be to create this monster.
Then the paranoia sinks in. People can't be this stupid. Really, seriously?
There are a lot of positives for "corporate amerika" (read anti-consumer) if we are all paranoid about our systems. if nothing is safe, you can bet someone will be trying to sell safety. In my best "tin foil hat" thinking, the people who perpetrate the insecurity in the first place and sell you additional safety, are not to be trusted.
There are lots of examples of "corporate amerika" teaming up to get you. RIAA and MPIAA are the more slashdot recognizable. A little paranoia may be just good thinking.
We need to remember that the computer is a revolutionary platform that continues to introduce disruptive innovations. "Corporate amerika" really really dislikes that which disturbs the status quo. The computer is too much of a money maker to destroy like they did DAT recorders. They are teaming up to make the computer more like a VCR or DVD player and less a platform of innovation.
Linux and free software is a problem for them because they can't control it. All they can control are the avenues through which we use our computers. The media formats, the services, etc. are all ways to leverage "corporate amerika's" assets against everyone.
I know this is all paranoia, but I don't think there needs to be an actual conspiracy for it to be true. "Corporate amerika" is anti-freedom, I think we can all agree that this is most always case. They don't have to intentionally work together, but a group entities with basically the same objectives may behave in concert toward an objective without conscienceless knowing it like a thousand ants from a single ant hill.
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.
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!
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.
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.
Huh? So remove the existing split of user and kernel and then split it back up again? Are you high? Have you heard of Kernel Ring Levels? Come back after you've taken an intro course to OS design.
That sounds like more nonsense. You have no clue what the heck you're talking about. If you deny any rights to "malicious" code you deny the same rights to "regular" code.
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