Research: Hacking the Chromebook (Part 1)

By now many in the bounty arena have heard of Google’s new Chromebook bounty totalling $100,000. While not as big as the infamous Zerodium one million bounty for iOS9, this one comes with a crucial difference – it is being offered by the manufacturer of the device in question instead of a security company with possibly shady customers.

In this series of posts, we will explore our attempts to break into the Chromebook, beginning with some basic exploration of the Chromebook while in guest mode.

What is the Bounty For?

According to Google, the bounty is being offered for the following:

participants that can compromise a Chromebook or Chromebox with device persistence in guest mode (i.e. guest to guest persistence with interim reboot, delivered via a web page)

This would preclude any kind of physical access methods, or exploits delivered while logged in using a non-guest account. This also would preclude exploits delivered while in developer mode which provides shell access.

Background

Chromebooks run Chrome OS, which is essentially a stripped down version of Linux with Chrome browser as its main interface. Most apps are either Chrome apps, or Chrome extensions, and can be installed from the app store. There is a main Linux user named “chronos” that runs most of the underlying system, with some specialized users for certain services, and individual user accounts are located in the “/home/chronos/u-XXXXX/” folder including the guest user. A fuller description of the security system can be found in this paper from MIT .

While in guest mode, only default apps/extensions are available, and new ones cannot be installed. Another important point is that guest mode uses tmpfs file system for storage, which is RAM based and does not persist.

Poking Around Chrome

At this initial stage, we have explored the Chromebook to see what possible avenues of attack may be possible. We started with looking at the Chrome browser itself. Here are some interesting things we found:

  • Chrome is running in incognito mode
  • Only the default plug-ins are loaded (chrome://plugins/) including: Chrome’s PDF Reader, Native Client, Widevine decryption, and Adobe Flash. This is basically the same as Chrome out of the box on other platforms. Screenshot below:
chromebook1.png
  • No extensions are listed (chrome://extensions/), HOWEVER, that isn’t really true. If you try to open certain files, it is clear from the URLs that there are hidden extensions installed. We did not look into listing them, but they should be easy to find on the Chromium source. Screenshot below:
chromebook2.png
  • Extensions cannot be installed via the Chrome store, OR manually by downloading and dragging them in. For the Chrome store, the install button is simply not there. For manual installs, message “Installation is not enabled” comes up.
  • Access and changes to flags is allowed (chrome://flags), but does not persist across reboots. Flags can be changed and take effect by restarting Chrome for the current session.
  • History, bookmarks, caches, etc. do not persist across reboots.

Download and Opening Files

You can download all files and open some of them:

  • Safe browsing is enabled and checks downloads against a blacklist.
  • Downloaded Office files (doc, xls, etc) open via an extension inside the browser that looks like a scaled down version of Google Docs
  • Downloaded Image files open in the browser but also can be opened with Gallery
  • Downloaded text and HTML files open in the browser
  • Downloaded sound and video files open via a dedicated sound and video player apps that pop up above the taskbar
  • Needless to say that possibly malicious files like shell scripts, JS files, etc. do not open although we haven’t explored any possible holes there yet
  • There is no editor of any kind in Guest mode, full users can install apps to edit
  • File URLs are used for local files and it is possibly to introspect SOME directories (/tmp and /media)

Poking around the Desktop

Chromebooks also have a desktop of sorts which is really Chrome underneath. There isn’t much available other than Chrome itself, the Files application and Help.

  • The Files application gives access to the Downloads folder and any USB drives that get plugged in. It can rename, move and delete files and folders but not much more than that. Because it is restricted to the Downloads folder only, it is not possible to see the rest of the files system. It is also clear via the Files application that RAM is being used, since the space available is less than 1 GB versus much more for regular users (no quotas are enabled).
  • As mentioned earlier, Gallery, video and sound players are available by clicking on the right files.
  • There is screenshot functionality available via a hot key
  • Lower right corner provides access to settings such as Bluetooth, WiFi, etc.
  • There is a very basic and restricted shell (crosh) available by pressing CTRL-ALT-T but it is another Chrome extension with very few commands (in developer mode, it provides access to bash). Below is an example of top running in the shell (interestingly enough the W command in top can write files):
chromebook3.png

Possible Avenues of Attack

First of all, as stated above, the guest user’s home directory is using tmpfs, which does not persist. This would mean that we would need actually execute some code that would persist in the system OUTSIDE that directory and come back upon reboot. Here are some possible entry points:

  • Default Chrome plugins – via malicious PDFs, Flash files, video/audio with DRM or native client apps
  • Default extensions – these can be targeted via malicious files for the Office extension. Another possibility is to use Chrome’s built-in developer tools but that would probably be out of scope.
  • Chrome browser itself
  • Javascript APIs
  • Video/Sound can target the built-in audio or video player
  • Malicious images can target Gallery
  • The various settings available to the user can be exploited across multiple users
  • Possibly via other processes running in the system and their users

Second, even if we manage to break in and execute code, it would still only execute in the context of the chronos user. We would then need to figure out how to elevate privileges to reach root access.

Third, we would need to figure out how to get past verified boot. Google outlines some potential ways this may happen ONCE attacker has gained super-user privileges.

Conclusion

In this post, we have briefly explored some of the pieces of the Chromebook software with the eye towards exploitation. In followup posts, we hope to continue digging in further.