- Jun 16, 2014
- 781
Sandboxes are unsafe. VMs are better.
With proper restrictions and used correctly, sandboxes can be a perfectly safe and convenient method for malware testing. They are also great for mitigating drive by downloads.
However sandboxes have weaknesses that users need to be aware of (which many sadly aren't). Here are some commonly forgotten ones off the top of my head:
* Sandboxes redirect WRITE but usually not READ.
- Unless you specifically disallow a file/folder in the sandbox, any process running sandboxed has READ access to this file. Therefore if you also do not switch internet access off, or set up a DNS redirect (to redirect outward network traffic to your own computer), the malware can easily grab your browser profiles (history, cache, passwords etc) and send this to a remote server. Multiple users on this forum have been caught out by this during testing, please don't let it happen to you.
* Sandboxes restrict only USERLAND.
- If you do not disallow access to kernelland (ring 0), malware running in the sandbox may load a driver or begin a process in kernel mode. Indeed allowing any access to the kernel space in a sandbox means that sandboxed process has access to your entire computer, bypassing any asynchronous redirection the sandbox implements.
* Inherent weaknesses in sandboxes
- Please be advised that some sandboxes are just applications. They do not emulate hardware and as such are still vulnerable to attacks such as DOS and in some case escalation attacks which could allow the computer to become compromised.
Sandboxes were not designed to be bomb proof tanks, run malware carelessly in a sandbox with no regard or interest in it's configuration or it's architecture and internal method of working and you are asking for trouble. Exercise vigilance and caution and you will effectively mitigate most of these attacks and avoid the mistakes of many infected users before you