Adobe Launches Sandboxed Reader X 201
CWmike writes "Adobe on Wednesday released Reader X, the next version of its popular software that includes a 'sandbox' designed to protect users from PDF attacks. Protected Mode is Adobe's response to experts' demands that the company beef up the security of Reader, which is aggressively targeted by attackers. Calling the sandbox a 'new advancement' in protective measures, Brad Arkin, Adobe's director of security and privacy, admitted it will not stymie every attack. But he argued it will help. 'Even if exploitable security vulnerabilities are found by an attacker, Adobe Reader Protected Mode will help prevent the attacker from writing files or installing malware on potential victims' computers,' Arkin said in a post to a company blog late on Thursday."
Does this one work with Chrome? (Score:2, Interesting)
Acrobat Reader does this stupid thing where it opens the Reader application to show me an error message then shuts that down and opens the document in the browser. During this, any other Acrobat Reader instances opened will be automatically closed and it's a 50/50 shot whether the current document actually shows up properly in the browser.
Alternatives (Score:3, Interesting)
I personally use Sumatra at home, at work (I work at a print company so we receive lots of PDFs) we use Adobe Reader but I've made sure to disable JS by default in it. It's amazing just how many attacks disabling JS stops. The really impressive thing is that of the massive amount of PDFs work receives we very rarely have one that requires JS. The unfortunate reality of PDFs though is that Adobes Reader is the best renderer, whilst say with Sumatra or Foxit may get 5% rendered incorrectly that's a lot of needless support calls and hassle.
Plugins.... (Score:2, Interesting)
THe trouble with sandboxes... (Score:3, Interesting)
Any program I run should be have the option of being sandboxed by the the OS if I so choose.
I totally agree. The OS should provide hooks to applications to spawn sandboxes. I know that Apple already has this in OSX since I use it in Xgrid to sandbox jobs. They have not documented the configuration yet but it's easy enough to guess. It works well. It would be cool if they could take it a step further to the thread level so you could share memory but imprison the resources a thread can use.
I have found the tricky part of this is that many things you think you can turn off are not so easy. For example, many applications need to access preference files so they need read write to the preferences directory. Your code may not be actually writing to that directory but calling a persistence library function for dictionaries and it may require you to allow access to the whole directory not just a file.
In other cases your app may call other things that expect certain access. For example, when you run the command "ls -l" in a shell, it accesses /etc/passwd in order to put names to the process UIDs. When you ask for the time or date, various localization files in /etc are consulted. When you call open/save dialogs some of these appear to try to inventory the mounted drives in /Volumes (which you can see because the drives spin up).
It's hard to anticipate these things because libraries and APIs that you use have legacy expectations of their privileges. In order for the code to grant that access to the API, the code itself has to have it too. The only work-around for that is to go back to the evil days of Set UID root scripts (like the command "ps" still has).
Re:Does this one work with Chrome? (Score:2, Interesting)
Re:Air taggs along. (Score:3, Interesting)
yes, and the 3rd directory down in this link sums it up pretty well
ftp://ftp.adobe.com/pub/adobe/acrobat/ [adobe.com]
Index of /pub/adobe/acrobat/
Name Size Date Modified
[parent directory]
all/ 8/26/08 1:00:00 AM
js/ 1/25/07 12:00:00 AM
junk1/ 2/12/04 12:00:00 AM
mac/ 3/10/09 1:00:00 AM
misc/ 5/31/01 1:00:00 AM
unix/ 1/20/00 12:00:00 AM
win/ 8/6/08 1:00:00 AM
Re:Great Idea: Will it work? (Score:3, Interesting)
Sandboxing vi ?
Is vi a link to vim on your machine? If so, it might be worth sandboxing; there has been at least one security hole in vim in the last year or so that has caused a buffer overflow that is exploitable by maliciously crafted text files.
Fortunately, the slow download of Adobe Reader (Score:5, Interesting)
Gives you ample time to uninstall the McAfee Security Scan Plus that gets installed without your permission.
Re:The OS should provide the option to sandbox too (Score:4, Interesting)
Windows New Technology => WNT
(V+1)(M+1)(S+1) == WNT
Cutler didn't even pretend it was new.
NeXT figured it out ~18 years ago (Score:4, Interesting)
Back in the day, it was realized that Display Postscript could be exploited. This was demonstrated in an amusing way with encapsulated postscript files which, when NeXTSTEP's Mail program tried to render them in-line in a message, executed code that would cause your screen to "melt", or would grab all the windows on your screen and spin them around until you clicked the mouse.
Unfortunately, Postscript could also operate on files...
So NeXT added a default "secure DPS context" in which Postscript would execute with the problematic instructions disabled.
Re:The OS should provide the option to sandbox too (Score:2, Interesting)
I can tell you without a shadow of a doubt that if you replaced all the Windows machines with Linux tomorrow by next week those users inboxes would be full of "free_porn_codec.sh" or "Happy_puppy_screensaver.sh" with instructions that they WOULD follow to run them.
This is FUD.
You either do not know (or understand) what the "onion/layered approach" is regarding security.
An onion model assumes that vulnerabilities WILL happen, and therefore permissions are restrictive by default. If there is real world exploit on multiple levels, it is the OS fault.
Permissive systems assumes that no exploits will occur, or rather that all KNOWN exploits are now defended against (ok, job done, let's go home guys...). If there is real world exploit on multiple levels, it is the USER'S fault.
Guess which model has stood the test of time?
I get really annoyed when mouse jockeys try to say that Linux would be just as insecure as Windows IF ONLY MORE PEOPLE WERE USING IT. Your argument is based either on ignorance of UNIX, security, or out of defensiveness for your livelihood: you do profit from people's misfortunes using Windows. It is not your fault they run Windows and you enable that to continue - they choose this. So you shouldn't feel any need to emotionally defend Windows with an attack on Unix.
PS - if you actually TRIED sending "Happy_puppy_screensaver.sh" to a newbie who runs Linux, it would fail for more reasons than you could ever know.
It would be impossible for the Linux user to run emailed scripts by clicking in the email. Even if you had the user save the file, it would still not run. Even if you talked the user through how to enable the file's execute bit via chmod +x, it STILL would NOT infect the OS with malware. If you talk the user into running "su" to gain root permissions, only then are we talking real damage. THAT is what an onion layer is like.
Here's another example:
On UNIX, there is 1 permission to read a file, and a different permission to allow execution. These permissions go on users, files, directories, filesystems, and even partitions.
Windows thought it would be a great "convenience" to just assume if you have permission to read something, it must be OK to run it also...
The DOS/Windows way of "read permission + file extension == execute" was widely laughed at before Windows even existed. In fact when Microsoft wanted a secure GUI system, they actually did security the UNIX way (OS/2).