sandboxes, sandboxes everywhere

lysa myers drew my attention to some interesting developments in the sandboxing arena last week. at first i thought she might be referring to security companies adding sandboxing to their arsenal (which i'd really like to see more security vendors do), but that's not it at all. it's actually sandboxing being added to individual applications. not only will adobe reader now come with it's own sandbox, but dell is coming up with a sandboxed version of firefox too.

i have mixed feelings about this sort of development. on the one hand it's nice to see sandboxing getting more attention and use, and these efforts will surely bring the technique to the masses. but on the other hand i worry about the effects of baking sandboxing into applications - especially applications that might call each other.

if something is running inside a sandbox and it executes an external program, that program should also run inside the same sandbox (otherwise the sandbox is rather simple to escape from). what happens, then, when the dell kace secure browser (which runs in it's own sandbox) launches adobe reader (as it would generally be expected to do when you click on a pdf link)? would we have adobe's sandbox nested within the browser's sandbox? how would that work - specifically how well (or poorly) would it work? you may recall that google's chrome had it's own sandboxing right from day 1 but that there were problems coexisting with other sandboxing technology (that i discussed here). the conflict between chrome and sandboxie seems to have been resolved but, as more and more applications come with sandboxing baked in, further inter-sandbox incompatibilities seem like a pretty likely outcome.

not only is cross compatibility between sandboxes a problem, but the question of implementation efficacy is an issue too. chrome's baked in sandbox was easy to escape because chrome's sandbox wasn't complete. it was only able to sandbox a narrowly defined set of processes specific to the browser itself - it couldn't even sandbox the plugins that it ran in order to render rich content like flash. it stands to reason that any baked in sandboxing technology is only going to be good enough to sandbox the application it's baked into. if the sandboxing technology was good enough to handle all the secondary processes that an application might launch then the technology might as well be made into a general purpose sandboxing product instead of being baked into an application. some may be better than others and people may be lulled into a false sense of security by thinking that the sandbox baked into application X is as good at protecting them as the sandbox baked into application Y.

i'm a big proponent of sandboxing, but i don't think sandbox sprawl is a good thing. it would eventually replace a few discrete sandboxes with known properties and known shortcomings with a ridiculous number of sandboxes with unknowable properties and shortcomings and cross compatibility issues. i'd prefer to see users using one or two general purpose sandboxes than dozens of  custom sandboxes.

autoexecuting is baaad, m'kay?

automatically executing code has a long history of having bad consequences for computer users, from the windows autorun functionality that enables malware to spread to our computers as soon as we plug in a usb flash drive/mp3 player/digital picture frame/etc, to auto-executing macros in office documents that were used by macro viruses and other macro malware to compromise our systems as soon as we open the document, to the auto-execute nature of web content that helps drive-by downloads happen and prompted the development of things like the noscript firefox extension...

automatically executing things is convenient, sure, but that convenience is at the cost of security so when i saw this lifehacker post about an extension to let you auto-execute your downloads i naturally asked if this wasn't an unwise action to take... following that my ability to comment on lifehacker was been disabled (coincidence? or maybe it's like that time i became persona non grata on hoff's blog) so i can't follow up on responses there and have to do it here...

there are a couple of arguments that one might propose for why in certain circumstances the risks posed by this sort of extension might be mitigated... the first is that this extension is only for those who know and trust the site they're downloading from and therefore know and trust the program they're downloading... this comes from the long running advice to only download programs from sites you know and trust... unfortunately trust isn't transitive in that way (despite what that advice may imply), you can't know and trust code before you've downloaded it... the advice to only download from sites you know and trust is actually intended to get the user to avoid the high-risk behaviour of downloading from a site which may have intentionally malicious downloads on it, but it doesn't completely eliminate the risk of downloading harmful software... you can't say a program is safe just because it came from a trusted source - even microsoft has been known to inadvertently distribute malware... there's also the not-so-little problem of getting users to give trust wisely, and the problem of being able to tell a trusted site from a forgery...

the second argument for why the risks are mitigated is that your on-access scanner will scan the program before it runs anyways so users should be pretty safe... unfortunately, as readers of this blog well know, known-malware scanning (on-access or otherwise) is essentially ineffective against malware in the beginning stages of it's life-cycle and in recent times malware profiteers have been making greater use of ways to exploit that fact (using such things as server-side polymorphism, malware creation kits, or generally any method of creating a large number of different malware instances in a short period of time)...

there are, of course, other techniques for protecting yourself from malware (such as application whitelisting which will have no effect here because you would presumably add your download to the whitelist, or behaviour blocking which would require you to know what behaviour should be allowed) but one of the simplest approaches to this problem is to quarantine the download for a few days/weeks to give your anti-malware signatures time to catch up... this is sometimes referred to as a cooling off period...

another option is to run the program in a sandbox of some sort like a test machine or VM... you may already be running your browser in a sandboxed environment but i would argue that new downloads should probably not be run in the same sandbox as your browser because it may get access to sensitive information in that sandbox...

in summary, automatically running things you download is something you probably don't want to do... it's risky behaviour... new downloads should be tested for safety first and our ability to do a good job at that in an automated fashion is rather limited...