TQ
dev.com
Blog about software development
06 Jan 2018 - by 'Maurits van der Schee'
Our worst fears have been proven true. Sandboxed code execution on most Intel chips in the past 20 years has been unsafe. And it's even worse than that: there is no fix, as Intel has been trading security for performance with a technology called "speculative execution". For more information read about the Meltdown and Spectre CPU flaws. This post will explain the impact and what we can do about it.
People laugh at me when I tell them running untrusted code in a sandbox is doomed to fail.
"Dependencies are an underestimated risk and sandbox isolation is no reason to skip proper security screening."
It has been a theme in the past 10 years: more and more code sandbox technology appears and is trusted. First, virtual machines images became popular, then containers with its binary image exchange and last but least the unlimited supply of minified JavaScript packages that your browser executes without asking. Even if you trust the supplier of the code that does not make the code trusted, as the supplier may be depending on packages containing source code that was never checked (or compared with the binary/obfuscated distribution). If sandbox technology could be trusted this would all not be a problem, but the essence of the problem is that it can't and this has been an problem with Java applets, Flash and now with JavaScript.
When doing a clean install of Linux, I'm not worried that it contains malware as the Debian community does an awesome job at reviewing the (open source) packages and the images and its updates are actually signed. Also when I use commercial software I'm not worried, as I have the liability of the vendor that guarantees me the software will do no harm. But when I use a container image from somebody on the web then it is largely unclear to me who wrote it, what its dependencies are and who reviewed it for the existence of malware. And when I visit a website that runs JavaScript then I'm pretty sure that nobody (not even the site owner) has any idea whether or not the code contains malware. So I have some worries about virtual machines, a little more about containers and I'm worried most about JavaScript execution.
So Meltdown and Spectre have shown that you cannot safely execute malicious code in a sandbox. I think it is because the sandboxes are too complex and thus hard/impossible to lock down completely (especially these side channel attacks are hard to mitigate). Remember VENOM in May 2015? These kind of virtual machine escapes are found regularly. And what about those numerous local elevation problems in the kernel in relation to the use of containers? I feel there is a lesson that we should have learned from Java applets and Flash, before burning ourselves again on JavaScript (and the next horror: web assembly).
Instead of crying out "I told you so" and "the world has come to an end" let's be realistic and constructive. When the number of dependencies is low and the dependencies are open source, popular and signed then the risk is lowered as these packages can, and will be, reviewed. I don't see the need for virtual machines or containers outside a lab setup and I really don't understand why anyone would use them in production. If you do, then you are trading security for convenience or cost reduction and that does not sound right to me.
"Don't use virtual machines or containers in production: You're trading security for convenience."
When JavaScript dependencies are hosted on the same domain as the content, then we can simply trust the site owner to distribute a trusted version. Unfortunately the way that JavaScript based analytics and social media trackers work is inherently unsafe, loading the scripts (without asking) from a third party. They should be publishing open source, versioned and signed client libraries that can be downloaded and self-hosted. The way ad networks currently work is even worse as the advertisers can push any JavaScript code to the people viewing the ads.
Avoid sandbox isolation based security if possible. Install Firefox 57.0.4 with the Meltdown and Spectre patches and install the "uBlock origin" ad blocker, blocking as many ads and trackers as possible (using the "anti-social" and "easy privacy" block lists). Next to that install the "NoScript" browser add-on to block JavaScript on any site by default and only add sites that you trust. Check the dependencies on container images that you are about to run and never run containers from untrusted source. Use an official distributed operating system image when installing a virtual machine and verify the hash. And never run untrusted code in any of them. If you need proper isolation, then you should use a separate machine. And if you are a site owner then you may rethink your JavaScript dependencies (this site runs without any).
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.
Subscribe