Google’s ChromeOS, at first glance, is something of a touchdown for operating system security. It’s probably the most secure operating system in the world (at the cost of some limited functionality ). Unfortunately, ChromeOS isn’t a panacea, and serious security concerns about the platform remain.
First, though, the good news:
ChromeOS (the stripped-down linux operating system that runs on inexpensive Chrome-branded netbooks ) has a bunch of really nice features for security-conscious users. The bootloading code is stored in read-only memory, and checks the digital signature of the OS kernel prior to boot-up (the “verified boot” feature). Because the bootloader is in ROM, hackers can’t possibly modify it without physically tampering with the chip. If the system files fail the check, the bootloader will simply reset the entire machine to factory settings, destroying any malicious code that might have been inserted.
The security of the platform is further strengthened because it’s based on web apps, which are run in a sandbox: their threads and memory are kept separate, theoretically preventing a malicious web app from accessing information or taking control of other apps. System updates containing security fixes are applied automatically and invisibly when the computer is connected to the network, to ensure that Chromebooks are always up to date. There are even a few security options you can enable to protect the device from attackers with physical access to the device. Trying to get malware onto a ChromeOS machine is not an enviable task. You can read more about the security of the ChromeOS platform here.
So what’s the problem?
You Can’t Trust the Sandbox
Unfortunately, the security offered by web sandboxing is largely informal and unproven. Plenty of sandboxes, including Java, have had bugs discovered that allowed applications to get out of them and execute arbitrary instructions on the machine. Chrome itself has had sandbox-breaking attacks demonstrated against it by black-hat hackers. Those specific exploits are now fixed, but there’s no guarantee that there aren’t more. Rik Ferguson, a security researcher, puts it like this:
“Exploits that break out of sandboxing have already been demonstrated for Internet Explorer, for Java, for Google Android and of course for the Chrome browser (to name but a few), while the Google sandbox is effective, it is not impenetrable and to rely on it for 100 per cent security would be short-sighted.”
The worst offender here is the interactive web, particularly webGL, an implementation of OpenGL (a common graphics library) intended for use in web browsers. WebGL lets you run graphically impressive 3D demos from your browser, which is really cool (such as these examples), but, unfortunately, it’s also a nightmare for security. WebGL allows web apps to send arbitrary shader instructions to the video card of the machine, which allows a whole imaginative rainbow of possibly sandbox-breaking exploits. Microsoft’s official position is that webGL is too insecure for internal use:
“The security of WebGL as a whole depends on lower levels of the system, including OEM drivers, upholding security guarantees they never really need to worry about before. Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise. While it may be possible to mitigate these risks to some extent, the large attack surface exposed by WebGL remains a concern. We expect to see bugs that exist only on certain platforms or with certain video cards, potentially facilitating targeted attacks.”
You Can’t Trust the Cloud
Even worse than possible threats against the sandbox, though, is the nature of the platform itself. Chromebooks, by design, depend heavily on the cloud. If you accidentally destroy your Chromebook (by, say, stepping on it or dropping it into a lake of molten rock), your data isn’t gone. You can just buy a new one, log in, and get all of your data and settings back.
Unfortunately, this exposes users to considerable risk on the cloud side of the equation. Sean Gallagher of Ars Technica points out in his editorial “Why the NSA Loves Google’s Chromebook,” we know that the NSA has had (and may still have) invasive backdoors into Google’s cloud storage, and can use that to spy on all of the files of Drive users, including those using Chromebooks. As Gallagher puts it,
“None of this is necessarily Google’s fault. But it’s a weakness of the browser as platform—by pushing nearly all the computing resources for applications, besides presentation, back up into the cloud, the Chromebook model creates a one-stop shop for attackers or observers to inject themselves into your computing world.”
It’s not just the NSA, either. While the trusted bootloader can protect you from persistent, malicious modifications to the operating system that report on your doings, even a single security breach by a web app could be enough to steal your keys and authentication details, which an attacker could then use to access your cloud data and browse it at their leisure.
Native Apps are Coming
To make matters worse, ChromeOS’s sandbox isn’t a particularly pure paradigm: the browser extensions that run on top of web pages, like Adblock Plus and Google Translate are native code running on the machine, and they can do all kinds of nasty things (including displaying adware and spying on your passwords). There are even extensions you can download that detect and remove other malicious extensions – a form of the anti-virus software that ChromeOS isn’t supposed to need. To Google’s credit, ChromeOS will only install apps from the Chrome extension store that have already gotten through Google’s approval process. Unfortunately, that vetting process relies on human judgement, and the guarantees provided by that vetting are much weaker than those provided by good sandboxing.
It gets worse: Google plans to implement native apps in the form of Android apps, run in ChromeOS via an interface layer. These would be native apps that introduce a whole breadth and depth of security concerns to ChromeOS, and those security concerns are made more serious by the relative vulnerability of the cloud to key theft. Breaches are more serious when they’re invisible and persistent.
Now, of course, any Android apps allowed onto ChromeOS will presumably be carefully vetted by Google’s team for malicious code, but that’s simply not a strong enough guarantee to hang the security of the machine on. Even if the code isn’t malicious, they’ll almost certainly come with their own exploits and vulnerabilities that could be used to gain access to the operating system. Native code is dangerous, and violates the security principles that are intended to keep ChromeOS safe.
ChromeOS: Secure, But Concerns Exist
It’s worth taking a moment here to reiterate that ChromeOS is very secure. If you’re using Windows, Linux, or OSX, ChromeOS is leaps and bounds more secure. In fact, that’s true of basically every operating system except Plan 9, a hyper-secure operating system so obscure that it avoids malware at least partially by not having any ‘ware’ to speak of. However, don’t take that as an excuse to be careless: serious security concerns about ChromeOS remain, and it’s worth being mindful of them when you trust your computer with sensitive information.
Image credits: Hacker with a Laptop Via Shutterstock, “Chrome Lapel Pin” by Stephen Shankland, “Chromebook“, by slgckgc, “Chromebook foto test“, by ?? ?, “Kryha-Chiffriermaschine, Kryha-Encryption Device“, by Ryan Somma