{"id":902,"date":"2016-07-22T12:00:52","date_gmt":"2016-07-22T10:00:52","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=902"},"modified":"2023-08-06T21:54:57","modified_gmt":"2023-08-06T19:54:57","slug":"defense-in-depth-a-present-time-example","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2016\/07\/22\/defense-in-depth-a-present-time-example\/","title":{"rendered":"Defense in Depth: a present time example"},"content":{"rendered":"

\"DarkWhenever 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,<\/a> the niche operation system for web users, and its techniques to keep its users save.<\/p>\n

<\/p>\n

Chrome OS<\/a> 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.<\/p>\n

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.<\/p>\n

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<\/a>): security.<\/p>\n

Security objectives<\/h2>\n

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.<\/p>\n

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.<\/p>\n

First layer: Browser and attack surface<\/h2>\n

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<\/a> to protect against common attacks, a few of them are explained here:<\/p>\n

Transport security<\/h3>\n

Chrome uses Public Key Pinning<\/a> as one component to prevent man-in-the-middle-attacks on secure connections.<\/p>\n

Public Key Pinning mitigates the threat of certificates being issued in someone else’s name, as happened in 2011 with Google and DigiNotar<\/a>. 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.<\/p>\n

Sandboxing<\/h3>\n

All tabs and plugins in Chrome are sandboxed<\/a> 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<\/a>:<\/p>\n

    \n
  1. 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<\/a> is using to isolate its containers, which is creating an unprivileged user namespace for each process.<\/li>\n
  2. The second layer protects the kernel by filtering system calls<\/a>. This prevents the sandboxed process from running any commands that could be harmful to the system.<\/li>\n<\/ol>\n

    If you want to check which type of sandbox is active on your system, type the following command in the URL-bar of Chrome:<\/p>\n

    chrome:\/\/sandbox\/<\/pre>\n
    Similar to the two layered sandbox architecture, the implementation of Chrome itself uses two layers<\/a> to incorporate the sandbox into the browser:<\/p>\n
      \n
    1. 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.<\/li>\n
    2. 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.<\/li>\n<\/ol>\n
      Reducing the attack surface<\/h3>\n
      With the deactivation of the NPAPI<\/a> the Chrome developers tried to reduce the attack surface by shutting down old error-prone interfaces.<\/p>\n
      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.<\/p>\n
      Second layer: File System access<\/h2>\n
      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.<\/p>\n
      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<\/a> (also nosuid<\/a> and nodev<\/a>) flags by Chrome OS. The attacker can only save data there without any chance of executing them.<\/p>\n
      The next plausible place to look would be the root partition . Chrome OS even has two of them<\/a>. One of them is used as the actual root partition, from where Chrome OS is operating, the other one is used for auto-updating<\/a> and fail-safe. There are several mechanisms hindering an attacker from writing to the root partition:<\/p>\n