Can we trust CloudMagic?

My Google Mail account is over 8 GB in size (thanks, attachment whores!), and includes over 70,000 conversations in my Inbox (ignoring the Archives). Unfortunately, this means that most search queries normally take 5-10 seconds, and this sucks, especially when you’re searching your email for that crucial information and your co-worker is looking at your personal email over your shoulder. I thought Mail.app or Thunderbird would be a solution to this with a local, SSD-backed index, but those programs search even more aggravatingly slowly (guys, can we fix this please?).

Enter CloudMagic, an extension for Chrome and Firefox that downloads and indexes your mail your for you. It will also index your Google Docs, Spreadsheets, and has plenty of other shiny features, but I’ll let you watch their demo video with the disturbingly generic narrator yourself. But can we trust this small company from Bangalore with our username and password? Will they misuse our data? Let’s take a look…

All Chrome extensions are distributed as .crx files, which are really just glorified .zip files with a little bit of Googley information tacked on. This lets us peruse some of the code of the extension, including the javascript and markup used to manage the extension’s basic functions. Poking around, the only interesting bit is where an innocuous-looking javascript file is downloaded from https://www.cloudmagic.com/res/2_71_Beta/php/initapp.php and used to inject a script into Gmail, Google Docs, and Google Calendar to provide a custom search box on those pages. There’s a good reason for this – if Google’s web interface changes, the company needs to be able to quickly update the script to prevent things from breaking, even if the Chrome Extension hasn’t been updated yet. Unfortunately, this is also a weakness – if the CloudMagic server ever gets compromised, replacing the script would allow an attacker to gain access our data as well. The question then becomes how much you trust CloudMagic to keep their server secure. Considering how big a target it is (thousands of Google accounts) and how small of a company it is, I’d rather play it safe and prevent the extension from loading any javascript remotely. A similar situation exists for the autoupdate mechanism, which allows the extension to update itself without any user intervention (and also passes a unique identifier to their website).

Another problem: you are required to enter your Google Account credentials into the extension preference page. This provides the extension with unlimited access to your account, and how much do you trust them with the password? Fortunately, this password appears to be stored locally only and is transmitted only over secure channels. A better alternative would be to use OAuth, wherein you give your password directly to Google, whose servers in turn provide an authentication token to the extension. The authentication token would only provide access limited to what is required by the extension.

Finally, there’s all the hidden code that’s compiled specifically for each platform via the NPAPI plugins. The Google Chrome developer page says it best:

NPAPI is a really big hammer that should only be used when no other approach will work.
Code running in an NPAPI plugin has the full permissions of the current user and is not sandboxed or shielded from malicious input by Google Chrome in any way. You should be especially cautious when processing input from untrusted sources, such as when working with content scripts or XMLHttpRequest.

There’s not much to find out or do here without the source code. However, we can look at the behavior of the extension with Little Snitch and Charles. The result: the traffic between the extension and its website appears innocuous (just the aforementioned update queries and script requests). It seems that the NPAPI plugin is doing its business entirely locally.

I should acknowledge that Chrome and all other Chrome extensions also use an autoupdate mechanism, so many of the issues pointed out here also apply to that software. However, in many cases those plugins are completely open source and reviewable, have a larger user base, have less access to my data, or I simply trust the vendors more.

Let’s recap the potential security issues:

  • Remote Javascript injection
  • Autoupdates
  • No OAuth
  • “Public” NPAPI plugins

I’ve modified the plugin to solve some of these issues, but it’s no Panacea.

This entry was posted in Pub. Bookmark the permalink.

Leave a Reply

Your email address will not be published.