Tuesday, February 21, 2012

Chrome addons hacking: want XSS on google.com?

For a few days now I'm checking various Chrome extensions code looking for vulnerabilities (see also the first post of the series). There are many. Most of them due to lazy programming (ignoring even the Google docs on the subject), some are more subtle, coming from poor design decisions.

As for the risk impact though, there are catastrophic vulnerabilities. This is just a sample of what code is committed to Chrome Web Store and can be downloaded as a Google Chrome extension.

How would you like an XSS on google.com?

Chrome extensions can alter the contents of a webpage you're navigating (if they have the permission for the URL). In web security, what is the worst thing you might do when altering HTML document on-the-fly? Of course, XSS. Even if the page itself is totally safe from XSS, an addon might introduce it (it's similar to just entering javascript:code()in address bar) and the page cannot possibly defend from it (more or less).

Google documentation about Chrome extensions warns about this exact threat. But, as it turns out, seeing is believing, so there you go. Let me tell you about some minor extension (196 users as of now, which is the only reason why I'm 0daying now) that allowed me to XSS Google.

Meet Linkify

Linkify Code Review URLs for Google Reader is just what it says on the cover:
If you follow Chromium Code Reviews inside Google Reader, you do want the ability to click on a link. This extension is there for that. And just that.
It upgrades link-like texts for a certain domain in Google Reader site to <a>nchors. How does it do it?
// manifest.json
   "name": "Linkify Code Review URLs for Google Reader™",
   "version": "1.0.0",
   "description": "Does what it says",
   "content_scripts": [ {
      "all_frames": true,
      "js": [ "ba-linkify.min.js", "jquery-1.6.2.min.js", "content.js" ],
      "matches": [ "https://www.google.com/reader/*" ],
      "run_at": "document_start"
   } ]
It attaches 3 JS files from extension code into any document from https://www.google.com/reader . The main logic in those files is:
window.addEventListener('DOMNodeInserted', handleEvent, false);

function browseAndLinkify(node) {
  if (!node) {
  if (node.children && node.children.length > 0) {
    $.each(node.children, function(index, element) {
  } else {
      if (node.innerHTML.indexOf('http://codereview.chromium.org/') > -1) {
        node.innerHTML = linkify(node.innerHTML);

function handleEvent(event) {
So every node in the document, when its HTML contains 'http://codereview.chromium.org/', gets linkified (linkifying is converting http://anything to <a href="http://anything">anything</a>)and reinserted it into the DOM using innerHTML. Which smells like XSS.


Manipulating any node in Google Reader to start with http://codereview.chromium.org and having the XSS payload bypassing linkify engine is very simple. In Google Reader search box just start searching for:

http://codereview.chromium.org/"onmouseover="if(!window.a){alert(document.domain);window.a=1}//" ddd

and mouseover. Or, even better,  visit this handy URL (of course, with the extension installed):


Voila! XSS on www.google.com

Lessons to take

Google Extension authors - don't use innerHTML with anything outside your control. Really!
Users - pay attention to what you're installing.


Amit Kumar said...

Thank you,
The given information is very effective.
I'l keep update with the same.

home decoration and accessories

pseudo_teapot said...

heh, pretty cool... I wonder if there are any extensions that add distributed content to pages in google's domain zone - that would be mega-pwnage ;)

specificationByExampleRoolz said...

A lot of extensions request access to your browser X, Y, & Z... but since you (the user) wants to use the provided functionality in the extension, we all click "OK".  Just from those notifications, it is still unclear WHY the extension needs those access permissions, or WHAT the extension might be doing with that access.  

How can we know/understand more about this process?  Where is the source path of the extension & should we just be looking at the source code (assuming dev experience).

JawBfl said...

I think that you can get more than just extensions .. you can use any other chrome's pseudo protocol I guess I'll try !!  

pogue972 said...

Theres a little bit about these scary warnings and what they mean on a section of Google Code's website, but its written more towards extension authors than end users. 

Juho Nurminen said...

I was actually annoyed by the very same thing, so I wrote an extension, the 'CRX Inspector', to address the issue. It'll let you browse the source code of extensions without making you install them first. Look it up in web store if you like.

As for the XSS vulnerabilities: the disturbing thing is, that small unpopular extensions built by ignorant amateurs are *not* the only ones you'll find them in. I've found several in hugely popular ones - including AdBlock and a number of 'by Google' extensions. Sloppy coding practices, e.g. the use of innerHTML, are putting millions of users at risk.