2013-03-09 23:48:02
By Tim Brown
In my previous post on the Acer ChromeBook, I discussed the Crosh shell. Today I'm going to examine another default extension which I mentioned previously which had caught my eye.
By default, the Chrome OS gives only very limited access to the file system. The File application extension is the only intended method by which a user can interact with their files, be they stored locally (in Downloads) or held on a user's Google Drive.
As an aside, I have however identified that it is also possible to access the following locations using file://:
Attempts to browse outside of these locations results in the Error 10 (net::ERR_ACCESS_DENIED): Unable to access the file. page being dislayed.
The first thing to note about the File application extension is that unlike many extensions which are part of the core of ChromeBook OS, this extension isn't listed in chrome://chrome-urls/ and indeed, there is no obvious way to load into a tab to inspect or manipulate it with the JavaScript console.
Happily (at least from a researchers perspective), I discovered that there was a bug within this extension which allows limited HTML to be injected into the File extension DOM. To trigger this, it was possible to search for <a href="">test</a> and then click the newly created link to load the File application extension into a tab allowing you to abuse it using the JavaScript console.
For those of you perhaps unfamiliar with web application security, this is a classic example of CWE-97, DOM-based cross-site scripting.
If you're wondering why I didn't inject anything more useful, extensions such as the File application have a Content Security Policy. In this instance, the developers have wisely chosen to set both the object-src and script src to none. Attempts to inject active JavaScript will therefore trigger an error in the interpreter.
Having loaded the File application extension into a tab, I began to examine the source from the JavaScript console. This lead me to a second interesting observation, in the form of the following snippet:
var dialogTitle = this.params_.title || defaultTitle;
this.dialogDom_.querySelector('.dialog-title').textContent = dialogTitle;
We can see here that it takes a title parameter from the query portion of the extension URL and inserts it into the DOM. Unlike the previous example which uses innerHTML however, as you can see, in this case the use of textContent by the developers ensures that injected iframe isn't active.
So what does the ability to load application extensions into a tab give us? The File (and other similar OS) application extensions will often expose a significant number of natively implemented objects and functions which would be ripe for abuse. The File application extension exposes a number of APIs of which two in particular caught my eye:
We can inspect and manipulate these and other APIs exposed by extensions using the reflection and tab completion capabilities of the JavaScript console to great effect.
The results from pwn2own at this years CanSecWest clearly show that more exploration of these and other APIs exposed by the Chrome browser which forms the core of the ChromeBook OS is certainly needed.
Note: The cross-site scripting bug I described at the beginning of this post is now fixed :(. Fortunately, all is not lost :), simply open chrome://files in a tab and we're back in the game.
Mood: Stuffed
Music: Pegboard Nerds - 20K
You are unknown, comment