2013-01-07 03:12:12
By Tim Brown
After some fairly heavy advertising from Google, I was recently persuaded to stump up the cash for an Acer ChromeBook. This post discusses some of my initial observations.
Whilst the ChromeBook can be run in a developer mode, I have so far opted to avoid this, with the intention of hunting for bugs that can be exploited as a typical user. Most of my explorations so far have revolved around the default extensions that are shipped by default. Two in particular have caught my eye so far, notably the Crosh shell and the File application so let's look at them in a bit more depth.
The Crosh shell is actually a bash script which wraps a number of diagnostic utilities and exposes them via a Chrome tab. It can be accessed from within Chrome using the keyboard shortcut of ctrl-alt-T. Whilst the script and indeed bash itself is fairly well locked down, there are a few of places where it shows signs of weakness. To wit, only commands that have a corresponding cmd_ function defined within the Crosh bash script can even be executed.
Despite the obvious limitations, since it uses bash beneath the surface, it supports file glob()'ing. To see this in action, from the shell run something such as dummy *. Whilst dummy is not a valid command, due to the way the shell works, the asterisk will be expanded. If you hit the up arrow after execution, you'll see that your entered command has been expanded to list the contents of the root directory. This can of course be expanded upon through the use of more complex glob()'ing patterns.
So what commands does Crosh actually give us access to? The most obviously interesting ones are ssh and top however they are both sadly locked down to prevent any useful interaction with the underlying OS. Whilst the parameters that can be passed through to ssh are whitelisted I had hoped that I might be able to escape from it post-execution using the ~C shortcut however this appears to be disabled. Whilst top won't allow us to interact with the OS it does however allow us to determine that the Chrome OS security model differs significantly from that of Android, Google's other GNU/Linux based OS. As those of you that have dabbled with Android will no doubt be aware, applications running on Android devices utilise unique per-application OS accounts as their primary method of sandboxing. Chrome OS differs in this regard since all applications effectively run from within the Chrome browser which runs as the chronos user. Whilst other commands within Crosh also accept limited input, a number of these are implemented as follows:
cmd_whatever() {
/path/to/whatever "$@"
}It's then the responsibility of the binary (which is often a script) to process the input responsibly. Sadly I haven't found any useful way to leverage this fact as yet.
Since Crosh itself, is fairly limited, my next thought was to examine if the extension responsible for loading it could be subverted in any useful fashion. Examining the JavaScript, notably crosh.js using the JavaScript console, I came across the chrome.terminalPrivate.openTerminalProcess() call that looked interesting however reading the source, it whitelists what can be run using this JavaScript extension. The best we could do here was trigger OOM by starting hundreds of Crosh processes simultaneously.
Mood: Hungry
Music: Nothing playing right now
You are unknown, comment