2010 Will Be the Year of Sandboxing Apps

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

Wow.... Welcome to Java applets, 1995...

[haemish]

Sandboxes are a tried and true idea, they work well. It's about time

Already here. It's on my family PC..

[Lumpy]

sandboxie... Great program, will NOT work on a 64 bit OS.

IT has kept my Daughter's PC free of crap because she refuses to not click on everything and not use Internet explorer... so I sandboxed it. Click on everything, it's all sandboxed.

Re:And the year of..

[Anonymous Coward]

Exchange takes the file cache into account when setting its cache size. If you start paging it can reduce its memory usage. The point here is subtle:
Free memory = Bad (wasted resources which can be used to reduce I/O)
Paging = Bad (bad performance)

So Exchange increases its memory usage unless the machine is paging.

you mean like an operating system is supposed to?

[Locutus]

really? sandboxing desktop apps? Look at what one of the design goals of any real OS is and providing security, memory protection( from other apps and OS space ), indirect access to hardware, and smooth multitasking between apps and OS are right up there near the top. Memory protection is WAY up there near the top unless you're looking at special purpose realtime applications or micro-controller apps. Now what we are seeing on Windows is yet another layer in an attempt to fix a bad design and one which will continue to slow down the system while pushing the hardware. It's great if you are out to sell more expensive hardware and you don't want lower end( cheaper priced ) hardware to run your software. You know, like how Vista ran so good on netbooks and how Windows 7 is better than Vista at that but still worst than Windows XP.

Sandboxing is basically what virtual machines like VMWare, VirtualBox, KVM, VirtualPC all do. Off of Windows, it gives users a way to run Windows without rebooting their main OS. On Windows, it gives businesses a way to keep one crashing Windows server from taking down the other servers and in the desktop it lets users boot Linux without rebooting Windows. But for app protection? That's what the OS is supposed to be doing.

LoB

Whatcha gonna do, if the CPUs don't sell anymore..

[Hurricane78]

...because nearly nobody needs even more power...

Just sandbox everything, and sandbox it again, then interpret, sandbox, and interpret again. Until you can barely get the framerate of a small handheld console from 15 years ago (remember that JavaScript Tetris?)

Just don’t feel the urge to actually write clean code. And cling to C-like languages, ’till the bitter end. Since C in a generic VM is oh-so-much faster, than Java (in its Hotspot VM) or Haskell on the bare metal...

Yay. I wonder how much I will kick the butts of others by writing clean straight-to-the-metal code without having to micromanage (C-style)... ;)

Instead of validating inputs

[vlm]

Cool, instead of screwing up the simple task of validating inputs, we'll simply screw up the complicated task of sandboxing. Awesomeness!

Fundamental Problem

[Ohio Calvinist]

The fundamental problem is that users want their computer to do things. They want responsive rich media web applications so conventional wisdom to turn off everything but HTML rendering causes their computer to not do stuff it used to be capable of. The second problem is that in order for computers to do things, particularly in networked environments, is that processes could be working with trusted, semi-trusted or untrusted stuff (be-it content, code, whatever, it doesn't matter for the purpose used.) When security tools attempt to figure out what ought to be trusted or not trusted and gets it wrong, you either do something unsafe or you block the user from doing what they want to do (even if you or me would consider what they want to do as foolish or downright dangerous.) When users are expected to indicate what is trusted or not trusted they generally lack the insight to know what to pick, and vendors are at peril of designing annoying software that provides little true security if users always click "yes" causing the unsafe action to happen, or prevents their computer from working as expected, if they always click "no." Sandboxing can be effective to limit access to other application's data, but can greatly limit interoperability and requires the developer make some decisions on behalf of the user, or makes the developer ask the user how isolated the process is from other resources in a way that is meaningful and they they can understand what the consequences in either case will be if they approve (ideally at setup).

How about reducing the surface area?

[argent]

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

Instead of adding a leaky sandbox, how about reducing the surface area exposed to attack in the first place? Simplify the application. Get rid of things like XPI in Firefox and ActiveX in IE. Get rid of the need for third party plugins like Java and Flash (HTML5 goes a long way here). Get rid of the ability for network apps to masquerade as local apps (there's no reason a web page should be allowed to remove the status and address bar, for example). Don't even *offer* to automatically open a file after downloading. Remove that option from the browser completely. Get rid of Acrobat and other plug-in document viewers.

Yes, this might make it less convenient for websites to "wow" the user. So what? I'd rather be safe than "wow"ed.

Re:And the year of..

[BlackSnake112]

Great Idea, but it looks like exchange is doing it wrong since the exchange machines I have seen are often using more memory then is installed so they are paging and using all the RAM it can. These are not the massive exchange systems that large companies have. These exchange systems have 5-20 email accounts on them. Not large at all. So why is exchange using between 5GB (on a systems with 4GB installed RAM) and 18GB (on a system with 16GB installed RAM) of RAM? I am not the exchange admin, I pointed it out and the exchange admin said not to worry the system is running fine. I still think something is very wrong.

Re:Windows 7

[wisty]

Doesn't FreeBSD has some sort of "jail" functionality? And has since the year 2000?

I'm not convinced that virtualizing a whole frigging OS is always the best. It's great for running XP or Linux on a MacBook; or XP on a Linux box (if Wine isn't enough), but the RAM use high enough to severely limit it's uses for security.

I'm not using a browser if it opens a new OS for every damn tab, for example.

OS tools (jails, lower level user accounts, etc) are going to be better. Or using a State Machine, or some other real engineering paradigm (instead of nasty hacked up code that kinda looks like it works).

Re:And the year of..

[LordLimecat]

Chrome uses a sandbox model, and it seems to do OK. Programs running in Sandboxie [sandboxie.com] seem to run pretty quick too. Is it possible not all sandbox apps are created equal?

I'll also note that IE8 has more security than IE7, and yet curiously runs much faster than its predecessor. Seems like security vs speed is a false dichotomy.

Re:Windows 7

[gbjbaanb]

you're looking at the chroot [wikipedia.org] command, Linux has it too.
It basically restricts an app to the directory and subdirs only, which only causes problems when they try to reach out of the jail to, say /tmp or /etc.

According to wikipedia, chroot has been around since... 1982.

(yes, FreeBSD jails [wikipedia.org] are better, but still based on the same concept).