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 …
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.
@adnim: Absolutely correct, it's a reader. Right, it's just A READER.
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.
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.
World + dog discovers VMS permissions
Wow, that only took 30 years. And no, Lunix hippies, file permissions are NOT the same thing.
Flashforward five years:
All I Needed to Read
"Borrowing a page from engineers at Microsoft and Google"
Well then, they are screwed.
Re: VMS permissions
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.
RE: Re: VMS permissions
"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...
If I remember right
The Register is an IT industry newspaper. Thanks for taking the trouble explaining to us that sandboxing is 'like airbags for apps'. So it only works if the programme is suddenly stopped, you mean? I'm like 'slow down professor' don't overwhelm us with technical details.
Oh no! Adobe Reader can hardly move under its bloatware now.
Oh no! Adobe Reader can hardly move under its bloatware now. What the hell's it going to be like when its sandboxed?
I hate to think.
Oops, too late...
The latest versions of most browsers sandbox plugins anyway.
That is all.
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.
By no means as many vulnerabilities but I believe one of the more recent PDF issues affected it as well (launching executables maybe?)
Airbags for apps
Thats some highly technical content there alrighty.
>Adobe has no plans at the moment to deploy a sandbox feature for Reader versions running on Max OS X or Unix.
I'm sure the folks in Redmond are really pleased to hear that only Windows needs extra protection.
Adobe could have done a lot more a long time ago
So no matter what new features they add, if they still set reckless & stupid defaults, they won't have helped.
And The Ultimate Fix Is
After installing Chrome (can be done on corporate PCs w/o admin rights, too), go to
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.
“We're not sure how the offensive community will react. They may move on to a different product and attack QuickTime instead."
I was wondering if anyone else noticed that dig at Jobs, liked it.
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!
- Nokia: Read our Maps, Samsung – we're HERE for the Gear
- Ofcom will not probe lesbian lizard snog in new Dr Who series
- Kaspersky backpedals on 'done nothing wrong, nothing to fear' blather
- Episode 9 BOFH: The current value of our IT ASSets? Minus eleventy-seven...
- Too slow with that iPhone refresh, Apple: Android is GOBBLING up US mobile market