Feeds

back to article Adobe to fortify widely exploited Reader with security sandbox

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 …

COMMENTS

This topic is closed for new posts.
Silver badge

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.

5
0
Thumb Up

@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.

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.

1
0

World + dog discovers VMS permissions

Wow, that only took 30 years. And no, Lunix hippies, file permissions are NOT the same thing.

1
1
Troll

2015

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.."

2
0
Flame

All I Needed to Read

"Borrowing a page from engineers at Microsoft and Google"

Well then, they are screwed.

0
0
Gold badge

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.

2
0
Stop

Not True

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.

0
0
Anonymous Coward

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...

0
0
Happy

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.

1
0
Thumb Down

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.

3
0
Silver badge
WTF?

Oops, too late...

The latest versions of most browsers sandbox plugins anyway.

0
0
Silver badge

http://xkcd.com/463/

That is all.

1
0
Bronze badge

Fuck 'em

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.

0
0
Silver badge

Re:Foxit

By no means as many vulnerabilities but I believe one of the more recent PDF issues affected it as well (launching executables maybe?)

0
0
Silver badge
Boffin

Airbags for apps

Thats some highly technical content there alrighty.

0
0

WHAP

>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.

0
0
Boffin

Adobe could have done a lot more a long time ago

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.

1
0
Go

And The Ultimate Fix Is

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.

0
0
Black Helicopters

Trust?

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.

0
0
Grenade

*giggle*

“We're not sure how the offensive community will react. They may move on to a different product and attack QuickTime instead."

*ouch*

0
0
Thumb Up

@*giggle*

I was wondering if anyone else noticed that dig at Jobs, liked it.

0
0
Alert

Huzzah!

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!

0
0
This topic is closed for new posts.