Instead of
sandboxing the reader they should simply take a magnet to all the storage devices where the source code resides.
It is a reader that is ALL that it should do. It shouldn't write anything.
Under criticism for being the world's most exploited application, Adobe Systems' Reader program will soon include a security design that's intended to thwart malicious attacks against end users. Borrowing a page from engineers at Microsoft and Google, Adobe is adding the a so-called sandbox feature to Adobe Reader for Windows …
Absolutely correct, it's a reader. Right, it's A READER.
I'm sick of being given crap excuses whether they're from Microsoft, Adobe or whoever for these ongoing and seemingly never-ending vulnerabilities.
Whenever I get right to the bottom of them (which is rarely because of obfuscation a compiler provides), I usually find out that it's poor or sloppy coding that's at fault. Moreover, often one can 'see' or infer how bad the code really is by watching other aspects of the way it works. Code that can barely stand up under ideal conditions and or which handles data in a sloppy or inconsistent way (sometimes crashing and sometimes not etc.) is likely to be vulnerable simply because it's been poorly engineered at its foundations.
Two points:
1. It's clear to me that as most commercial code doesn't come with source, that the developer has untold opportunity to obfuscate all sorts of bad engineering practices. Except for the medical practitioners, what other professions can you almost totally bury your failures and be assured that they won't come back to haunt you? Buy a car and the garage man can fix it, buy software and no one has a clue except the guy with the source code! Secrecy of coding breeds ignorance in end users (even other programmers and software reviewers are essentially blind w/o source), and ignorance puts you at the mercy of the coder/developer--as only he has the answers.
2. Many vulnerabilities exist because of the unsophisticated substrate these programs run on. The filing system in both Windows and Linux is antiquated--goes right back to the beginning of computing. For example, hello_world.txt is just text and a few unsophisticated attributes--that's it. The file--at the file level not the data level--has no advanced metadata structures--program, user, history etc.; nor has it any inbuilt file-level authentication and encryption etc. within the file structure itself (i.e. that remains with the file when transported to any other O/S). Schemas in use today only do this within the data itself, for example an Outlook PST file, however today there is no metadata at the file level (as encapsulation) except basic read write attributes. Similarity, the O/S can't distinguish its files from program files or user data except by primitive means--for example I can copy any file I want into the Windows\system32 directory. Why am I allows to do this? Really it's mad when you think about it. Except in special cases, unless a file is actually within Windows, there is no way of knowing that an orphan file actually belongs to O/S serial number xyz or program abc etc.
If the O/S used different formatting or whatever to stop certain classes of objects--files of certain types--ending up where they shouldn't--i.e. an intrinsic Chinese wall between system files, program and user-data files build on the basis that you cannot copy say a program file into the system directories simply because it wouldn't 'fit'--in the same way you can't put a square peg into a round hole or a 6mm thread into a 2mm nut or that standard gauge 4' 8 1/2" rolling stock simply won't run on 5' 3" gauge, then many vulnerabilities could be avoided.
No one is this smart in IT / Windows or Linux land, as everyone runs with a 'we-must-all-run-on-standard-gauge' file structures mentality thus penetration of the system is much easier than if the substrate were different for different classes of files. Look at it this way: if an army invades a country that has the same rail gauge all it has to do is put its own rolling stock on the line and away it goes. If the gauge is different the invader cannot use his own rolling stock and thus the invasion can be much more difficult (as was the case when Germany invaded Russia and struck a gauge that was not standard--and we know how that attack failed). Sure, nothing is guaranteed totally secure no matter what the schema, but what we have today isn't just a barnyard door vulnerability, it's citywide. We've no 'physical level' security protection only local O/S-based metadata protection, passwords, certificates, file-locking etc.
The fact is that these huge software corporations really haven't tackled the security issue properly or diligently, it's always been a Cinderella effort--everything returning to normal at midnight (i.e the moment users take their eyes off the ball). There has always been a piecemeal approach to fixing security and vulnerability issues because it's more profitable to pass the vulnerabilities off onto users, for at its core, they've little understanding of the problem. Unfortunately, the issue is little better understood by industry commentators and many security people. With no screaming pressure from IT professionals but only a whimper, and so after a crisis the big boys are back to sloppy business as usual. Thus, it's little wonder that we're left with the security shambles as we know it today.
Flashforward five years:
Adobe announces their new Adobe Reader 12 package which they promise will finally fix longstanding flaws in the product. New Adobe CEO Kent Ertugrul said "We have added six new layers of security, plus internal support for several new programming languages including Pascal, Occam, COBOL, BCPL and PL/1. You can now run native PL/1 applications directly in your Acrobat documents, which I am sure people will find just as useful as the long-standing Javascript support we have. All this, and you can read PDF documents too! All you need is to download the 5GB application from adobe.com, and install it on a system that meets minimum requirements of a 64 bit OS, an 8 GHz processor and 16GB RAM. Oh yes, make sure that your anti-virus software is up to date because you will be needing it.."
Actually, true to its VMS heritage, these have been NT permissions for 20 years and, in fairness to Microsoft (what!?) available in limited form in the UI as part of the RunAs command for 10 years.
But since no-one has used those facilities before, I think it unlikely that Adobe are intending to use them now, despite the fact that they've 20 years of testing behind them. No, my guess is that Adboe will invent their own sandbox, and that it won't be as secure as the operating system's one.
Google Chrome and IE8 use the Windos NT permissions in their sandboxes. Adobe is a follower.
Unfortunately Microsoft hasn't done the job properly - there is no way to deny a process accessing FAT file systems. You know, all those USB memory sticks use FAT.
Also, Linux and BSD have very strong mechanisms like LSM and Jails. AppArmor and SE Linux use it. And they also work with FAT, btw.
"my guess is that Adboe will invent their own sandbox, and that it won't be as secure as the operating system's one."
Not even as secure as something written by Microsoft?
Ha! The only way they could do that is to deliberately leave a backdoor open that lets hackers take over the machine...
Foxit does everything Adobe reader does without the vulnerabilities, so quite why anybody still uses the Adobe reader is beyond me.
@adnim - and do you apply the same logic to web browsers? By the same token they too are just readers so by your logic should no contain any vulnerabilities. Or maybe your logic is a little flawed.
If Adobe had just set the default on Reader years ago to not allow javascripts to run inside pdf's, they'd not have the sucky security reputation they have today. Reader & Acrobat today still default to allowing javascripts to run inside pdf's, and most people don't know how to disable that. (Hint: Edit -> Preferences -> Javascript, uncheck "Enable Acrobat Javascript", and hit "OK")
So no matter what new features they add, if they still set reckless & stupid defaults, they won't have helped.
http://www.google.com/chrome/intl/en/eula_dev.html?dl=mac
After installing Chrome (can be done on corporate PCs w/o admin rights, too), go to
chrome://plugins/
and enable the PDF viewer.
Then go to a PDF file, right-click and go to "open using" and select Chrome as the default PDF viewer.
The result is a lightning-fast PDF viewer which also renders HTML. And it has the same "airbags" Adobe has now bolted on.
If only chrome could be trusted to display a simple PDF without reporting back to the Chocolate Factory the name of the PDF and where you got it from, what other PDFs you've read, what other files you have downloaded since birth and what other software you have installed. Your PC spec and MAC of all connected items such as wifi AP. Your name, address, phone number(s), NI number, shoe size, hobbies & interests, sex and sexual orientation, voting habits and every other thing they can get a hold of down to your preferred colour of underpants. All of course with the 'do no evil' goal of assuring you only get targeted with adverts for undergarments of acceptable hue naturally.
Adobe have admitted that some of their software actually has flaws!
Not that any of us had noticed!
They still haven't managed to make a fully working version of Flash for mobiles. (I hope they never do, cos I hate it!)
The version on my laptop has an added feature - it turns the fan on!