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