Whenever we talk about multi-layered security, we always get to the see the image of an ancient medieval castle with high walls, moats and towers. In this post, we want to take a more present-time view on the concept of defense in depth. Therefore we are going to examine Chrome OS, the niche operation system for web users, and its techniques to keep its users save.
Chrome OS is basically a vehicle to start a browser on very cheap hardware. This fits the use case of many internet users who use their notebook and operating system mainly to communicate, browse the internet and watch Netflix.
It is built upon the Linux kernel, with the Chrome browser handling most of the “applications”. These applications are generally web apps, with the exception of the media player and file explorer.
In contrast to Windows, OS X or even Linux, Chrome OS was designed with one goal in mind (or at least this is the impression you get when you read their design documents): security.
Security objectives
Its security mechanisms are mainly designed to protect against random, optimistic attacks from the internet. This could be either stealing your sensitive data like passwords, or credit card info, or getting permanent access to your device to use it in a botnet.
We are now going to retrace the steps a malicious person would need to perform in order to attack a Chrome OS device. This shows us the layers of defense that are incorporated into the operating system.
First layer: Browser and attack surface
The first thing an attacker can use to carry out his evil plans is the browser. Chrome OS uses the Chrome browser (what a surprise). The browser itself uses several mechanisms to protect against common attacks, a few of them are explained here:
Transport security
Chrome uses Public Key Pinning as one component to prevent man-in-the-middle-attacks on secure connections.
Public Key Pinning mitigates the threat of certificates being issued in someone else’s name, as happened in 2011 with Google and DigiNotar. It allows the domain owner to pin certain certificates or certificate authorities as the only legitimate trust anchor for the domain. Any certificate not signed by these pinned certificates would be treated as fraudulent.
Sandboxing
All tabs and plugins in Chrome are sandboxed and isolated against each other as well as the file system to prevent malicious websites from snooping sensitive information from other sites you are currently logged on to, or from writing data to the file system. The sandbox in use basically consists of two layers:
- The first layer isolates the process running in the sandbox against the system environment. It restricts access to resources like the network interfaces or the file system. Therefore it uses the same Linux kernel features Docker is using to isolate its containers, which is creating an unprivileged user namespace for each process.
- The second layer protects the kernel by filtering system calls. This prevents the sandboxed process from running any commands that could be harmful to the system.
If you want to check which type of sandbox is active on your system, type the following command in the URL-bar of Chrome:
chrome://sandbox/
Similar to the two layered sandbox architecture, the implementation of Chrome itself uses two layers to incorporate the sandbox into the browser:
- The render layer displays the website the user has requested. Because it is interpreting untrustworthy code, this is the sandboxed layer. For each tab a new isolated renderer is created. It uses methods provided by the kernel layer for interprocess communication, file system access or memory usage.
- The kernel layer is handling all the management work. It provides an interface for communicating between render-processes, restricted access to the file system, resource management and memory management. Because the render-process only has access to the methods provided by the kernel, all actions can be monitored and secured.
Reducing the attack surface
With the deactivation of the NPAPI the Chrome developers tried to reduce the attack surface by shutting down old error-prone interfaces.
But still, there are zero-day exploits and browser weaknesses we don’t know about yet. So let’s assume, our attacker has managed to execute malicious code in the browser. Now its time for him to get permanent access to your device.
Second layer: File System access
The first thing an attacker has to do in order to get permanent access to a device is saving something somewhere which then can be used later. Therefore he needs write permissions on the file system.
The home directory of the user seems like a good place to start looking for them. Unfortunately for the attacker, this directory is mounted with the noexec (also nosuid and nodev) flags by Chrome OS. The attacker can only save data there without any chance of executing them.
The next plausible place to look would be the root partition . Chrome OS even has two of them. One of them is used as the actual root partition, from where Chrome OS is operating, the other one is used for auto-updating and fail-safe. There are several mechanisms hindering an attacker from writing to the root partition:
- Chrome OS uses Linux user permissions to restrict an ordinary user from writing to system critical files or directories. Even daemon users are heavily locked up. Access to the root directories is permitted only to the root user. This implements the principle of least privilege.
- Even the permissions of the almighty root user (UID=0) are modified and restricted. With the introduction of capabilities, features that previously required the root user can now be run with a less privileged one reducing the chance of the root user being attacked.
- While the operating system is running, the root partition in use is mounted read-only. So even if an attacker compromised the root user, he wouldn’t be able to persist his attack on the root partition.
But there are still bugs in the Linux-kernel an attacker can use to execute code. So let’s assume now he gained access to our system and written his code somewhere permanently. It’s time for him to survive a reboot.
Third layer: Verified boot
The verified boot process is the last line of defense in Chrome OS. It ensures the integrity of the boot loader, the kernel and the file system. Leading to only executing signed and verified code as a consequence.
Bottom-up security
To guarantee the integrity of the firmware, the boot loader, the kernel and higher systems, every single piece of software has to be verified to make sure that the following stage can be executed safely.
The root of trust for this entire procedure is a small boot stub. This little piece of C-code is baked into a read-only chip together with a public key. Because it is stored read-only it is impossible to change or bypass this step. With the public key the writable firmware can be verified. The firmware then verifies the integrity of the kernel, which then verifies the root file system.
The entire security of this verified boot process is based on the confidentiality of the private key that matches the read-only public key. Hopefully Google is aware of this responsibility. A disclosure of the key would render all existing Chrome OS devices vulnerable to attacks.
Resilience
If an attacker has altered data of firmware or the operating system, the verification of this stage fails. Chrome OS then has two options to cure itself from the infected partitions:
- If the attacker has infected the root file system it tries to boot the second root partition. Hopefully the attacker has only managed to infect one of the two. If the second partition is clean, the system can boot it and swipe the first one with a clean image of the current system.
- If this fails, the boot stub starts a restore routine also stored on the read-only chip. It instructs the user to load a safe copy of Chrome OS on a USB-Stick from another (hopefully save) device and insert the stick into his device. It loads a trusted USB stack which can be used to boot from the recovery stick and overwrite the infected partitions.
In either way the verified boot process ensures that an infected operating system is never loaded. This thwarts common attacks like Keyloggers. Those would be installed as driver in the kernel but the device would never execute them.
The concept of defense in depth
In this post we took a very sketchy look at the different security mechanisms of Chrome OS, from sandboxing in the browser to verified boot in the firmware. Stepping into the shoes of an attacker we came to see that no security system is perfect. Defense in depth takes this into account. The Google developers designed several layers of defense into the operating system. These layers are designed to add redundancy, narrow down the attack surface, mitigate the effects of a successful attack, or cure the system after an infection. This increases the overall security for the user.
Further Questions
This post was focused on the technical security aspects of Chrome OS. But there are some other questions that come to mind when talking about this operating system:
- Stolen user accounts or botnets are available in the Darknet for everyone. Plus they are not that expensive. But how will a more secure operating system affect this market? The cost of hacking an operating system that has been designed to be secure is obviously higher than hacking the typical unpatched Windows. So in theory, the prices for stolen accounts or botnets should rise.
- But does a wide distribution of a secure operating system only affect the Darknet market? Many attacks like phishing with spam waves depend heavily on a large number of hijacked devices. Will the overall security of the internet improve, if there are less vulnerable devices available to use as an attack vector? And if it does, is there a measurable threshold of secure to insecure devices?
- In their Terms of Use Google specifies which data are being captured while you are using your Chrome OS device. This should of course be validated by external reviews. The question beside the correctness of their Terms of Use is, how this data can be correlated and what they tell about you and what you are doing.
- As mentioned before, the security mechanisms of Chrome OS are designed to protect against random optimistic attacks from the internet. This leads to the simple question: Is it possible to hijack a Chrome OS device remotely (getting a root shell on the device and surviving a reboot) and how much effort does it take compared to hijacking a Windows or OS X device?
- Google recently announced that Android Apps will run on Chrome OS devices in the near future. But how will the introduction of this new feature affect the overall security of Chrome OS? Can Android Apps be imprisoned as securely as Web Apps, or even better?
Leave a Reply
You must be logged in to post a comment.