2010 Will Be the Year of Sandboxing Apps 203
Trailrunner7 writes "In a guest editorial on Threatpost, Mac hacker and security researcher Dino Dai Zovi writes that 2010 will be the year that software vendors get religion about sandboxing untrusted data in desktop apps. 'Instead of the usual top ten lists that are all-too-common with predictions for the new year, I have just one: 2010 will be the year of desktop applications handling untrusted data in sandboxed processes, and it will be about time. The largest Internet security threats now arrive through malicious web pages or e-mail attachments. This is because attackers are opportunistic and these are the weakest links especially because they easily pass through every firewall. Security is not and never was about SYN packets, it is about data: the software attack surface that attacker-controlled data interacts with and what sensitive data the attacker can get a hold of if they can exploit vulnerabilities in that software.'"
And the year of.. (Score:2, Insightful)
.. bloat.
Just look at how slow IE8 is to use.
Let's just stop using the browser as an OS. (Score:4, Insightful)
Maybe we should just stop using the goddamn browser as an operating system. It was never meant to be anything more than a way to view mainly static documents, and quickly access other linked documents.
While some interactivity is of course useful and sensible, some fools have gone off the deep end and think we should treat the browser as some sort of an application development platform.
Of course, anyone who has done real application development under a real operating system, even if it is just Windows, knows how poorly the browser is as such a platform. It's clear that everything, from JavaScript to AJAX to Flash, has been tacked on as a shitty afterthought.
The answer isn't sandboxing. The answer is that we need to go back to using the browser as just a browser, and nothing else. And any real applications that demand network connectivity should be written as such, and run outside of the browser.
requires sophistication & motivation; not opti (Score:5, Insightful)
All security problems are easy to solve if you have users who are sophisticated about security, and motivated to put up with inconveniences. The real world isn't like that.
A proposal like this inevitably requires that the user understand something about the sandbox, and also requires that the user go through various hassles because of the sandbox. They're going to perceive it as a hassle, because the sandbox is going to prevent them from doing things they would otherwise have done. If they're unsophisticated and unmotivated, they'll just see it as something to work around.
Not only that, but this isn't an optimal solution. A flash game has to be a Turing-complete program. A memo doesn't have to. The simple solution is just to stop embedding Turing-complete programming languages in file formats that don't require them. Adobe actually started by designing postscript as a Turing-complete language. That had some unfortunate consequences, since, e.g., you can't predict whether a program written in a Turing-complete language will halt, so in principle you can't predict whether a document will take forever to come out of the printer. The realized that that was a mistake, and when they designed pdf, they intentionally made it not Turing complete. Now we've come full circle, and they've added a Turing-complete language, javascript, back into pdf. That's just bad design. The solution for users is actually pretty easy: if you're using Adobe Reader, turn off javascript.
Offtopic Parent (Score:1, Insightful)
.. bloat.
Just look at how slow IE8 is to use.
What does this offtopic post have to do with sandboxing?
Re:Let's just stop using the browser as an OS. (Score:3, Insightful)
The answer is that we need to go back to using the browser as just a browser, and nothing else.
It's never going to happen. The browser is too useful for too many other things. If somehow we managed to get the browser to return to being just a page viewer, someone (like Microsoft) would create an API for online applications and call it a non-browser. In fact, this was the original idea behind .net, and why it is called .net. Online applications AKA cloud based applications are here to stay.
Re:Let's just stop using the browser as an OS. (Score:2, Insightful)
It was never meant to be anything more than a way to view mainly static documents, and quickly access other linked documents.
You are wrong wrong wrong. For many years now the browser has been meant for more than that. It originally may not have been meant for more than that, but to say it never was is stupid. The reason MS panicked about it was there was an express intent of making the browser more than that.
Re:And the year of.. (Score:3, Insightful)
unless you're using SBS, most organizations will only run Exchange or SQL or one major app on a server. on our servers we're running the HP software and SQL on our database servers. we even put all the third party database drivers on a separate server so as not to cause any potential issues.
Re:Already here. It's on my family PC.. (Score:5, Insightful)
Yes. Linux has many, many things that are pretty cool.
Unfortunately, they haven't had a good all-together tied-in user experience.
Claiming things like "we have chroot" and "we have sudo" and other code/geek-ish type of coolnesses is like claiming that your car has awesome engine with new piston technology, very secure door locks, and can run on almost ANY fuel currently available; unfortunately, the seats are rather uncomfortable and the controls on the dashboard look more like a commercial airliner's cockpit.
Yes, I know it's getting better. That's good. I hope they keep it up and continue to improve issues that apparently many geeks don't care about and many average users do (like flash video [youtube] and audio) and being able to use their iPods and scanners). :)
wha? (Score:3, Insightful)
Security is about everything, period.
Re:A wish, not a prediction (Score:3, Insightful)
Sandboxing is a decade late, we should be so much further by now.. dang.
Storm
Re:Let's just stop using the browser as an OS. (Score:4, Insightful)
Besides, it's been Microsoft's attacking of software application vendors on their platform which has lead to so much being attempted in the browser since it isolates them so much from Microsoft. You don't hear so much of what software vendors software broke at every release of a new version of Microsoft Windows. That's because more and more business applications are fed from app servers to browsers and a minimum standard feature set must be met in the browser for it to be useful across the web and therefore IntraNet.
This has little to do with the browser being the problem, it is about the design of the Windows OS not doing it's own memory protection and letting applications run many things as admin when they should be run as the user and they should not be accessing OS or other application space memory. This is another crutch for a bad design but it'll help sell more hardware if that's what you want.
LoB
Correction needed ... (Score:4, Insightful)
"unless you're using SBS " or run unix/linux " most organizations will only run Exchange or SQL or one major app on a server"
There, fixed it for you. Curiously unix can generally cope with running more than one app/DB without falling over or having one app
screw up the other.
"we even put all the third party database drivers on a separate server so as not to cause any potential issues."
Well that sums up running a Windows server doesn't it.
Re:you mean like an operating system is supposed t (Score:5, Insightful)
This isn't a Windows specific problem. The fundamental problem is the user/process model that's been popular since the inception of UNIX (maybe even earlier, I don't know enough about Multics to say): the idea that only users have identities and programs run under the identity (and permissions) of the user who runs it. If I'm running a game, there's no reason why it needs access to my tax spreadsheets, etc...
All software should be running under its own identity and access to user documents should be through standardized user interfaces... i.e., the 'File Open' dialog is actually a part of the OS not the application, and also grants temporary permissions in addition to just selecting a file.
We talk about the principle of 'least privilege' but in practice (with a few notable exceptions) the 'low-privilege' processes have the most important privileges of all: access to all our stuff.
Re:Instead of validating inputs (Score:4, Insightful)
Sandboxing only needs to be done right once. Validating user input needs to be done right every time. I'm not saying don't validate your user input, but if your first line of defense is a fairly brittle mechanism, having extra protection is a good thing.
Re:And the year of.. (Score:3, Insightful)
It's easier to snap-and-rollback a virtual machine than a physical machine when the user causes it to get pwnt.
It's easier to snap-and-rollback a sandboxed (jailed) app than a virtual machine.
It's easier (at least in Windows) to give the user admin control of his virtual machine than not. That doesn't mean he needs any sort of privledges on the host machine. Depending on the app sandboxing paradigm, the app can run as admin (as far as it knows), but the user doesn't have the ability to escalate the apps permissions.
From a security perspective, both VMs and app sandboxing are attempts to address the "user will escalate anyway" problem, and both are real progress over the pre-virtualizion norm IMO.
Re:A wish, not a prediction (Score:5, Insightful)
Not true.
All of these systems are designed to protect users from each other on a single system, when a computer was an expensive resource. It's just that unix had a good multi-user single-machine design long before windows did.
But the threat model these days is running untrusted code from the network. Very few machines actually have more than one user on them - they all have their own machines. And all of that code is running with the full privileges of the user, with access to all their data.
That is the. problem these days. And it's not one that unix is any better at solving than windows is. I would add that I've used Ubuntu as my primary desktop for the last 4 years - I'm no Windows fanboy - but neither am I blind to the security weaknesses of my chosen operating system.
Re:How about reducing the surface area? (Score:3, Insightful)
Sandboxing means that once the attacker has used an input exploit to own the process, it has to perform a privilege escalation exploit to get out of the sandbox. The problem is that applications running in sanboxes have to be able to write files, read files, load and install plugins, execute helper applications, and generally do just about anything a regulat application has to. So the sandbox can't be very "strong".
That's not really sandbox's fault, so much as the way that people design and run their OS. FreeBSD for example has the ability to combine flags and securelevel to prevent any changes to files that are so marked at all. It can be a pain in the ass, but it makes it very difficult for somebody to remotely install something to run at boot time.
Additionally, a proper sandbox shouldn't allow one to write to any portion of the hard disk that's directly accessible to the OS, and should really require exporting the information through the sandbox to access outside of the sandbox. If you're allowing the sandboxed app to operate directly on the disk you're doing something wrong and that area of the disk probably shouldn't be directly accessible except through a utility for doing so.