Adobe to fortify widely exploited Reader with security sandbox

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

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.

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.

@*giggle*

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