Chromium suddenly starts downloading a binary blob

A Debian bug that was filed at the end of May serves as a reminder that even open-source software is not immune to some of the problems of proprietary software. In this case, Chromium 43 was silently downloading a browser extension to enable the "OK Google" voice activation "feature" of the browser, which is somewhat reminiscent of the various sideloading schemes that plague downloads of "free" software, particularly on Windows. The download was a binary blob, of course, so its contents cannot be vetted in any real sense. As might be guessed, Debian developers were not amused, but it should also serve as a bit of a wakeup call to all of the free-software world.

The extension in question is called "Chrome Hotword" and the download is a native client (NaCl) shared module that includes executable content. Starting with version 43, Chromium could only be built with the extension, which would download the shared module at its first opportunity—all without user intervention or notification. Perhaps even weirder still, the extension did not show up in the usual chrome://extensions/ page. Its controls were available at chrome://voicesearch/, but users have to know it was installed and where to find that page.

To summarize, a popular open-source web browser does a surreptitious download of a program and hides the download and the existence of the program from the user. Even if the binary only does what it is purported to do, it can turn on the microphone and upload what it hears to a remote site to search for a key phrase. That description sounds a lot like one for the latest malware outbreak—or National Security Agency (NSA) eavesdropping program.

It is not (yet) clear how this came about—prosaic explanations seem most likely, in truth—but it did make its way into Debian unstable without being noticed. It was reported to the Chromium team on May 22 and fixed by adding a build option to disable the Hotword extension on June 9. The extension is still enabled by default, though, so builders who don't want that functionality need to turn it off before starting the build. By June 15, Debian had done just that and updated its version of Chromium.

There is plenty to be disturbed about here, but it seems pretty unlikely this was some deliberate scheme by Google (or the Chromium team). It would be hard to hide something like that in an open-source program like Chromium. But it is clear that the amount of independent review of the changes going into Chromium is less than what we might hope for. The value of open source is lessened if "many eyes" really turns out to be "zero eyes".

The contents of the executable should also be scrutinized, but there is no real way to do that. Even if Google is completely trustworthy with respect to what the program does (and there is no reason to believe it isn't) it is still a bit worrisome that your browser can simply execute whatever code its corporate master orders it to. Though, in some ways, that isn't terribly different from Flash or JavaScript. We are increasingly required to trust the various sites, companies, and organizations that we deal with on a daily basis on today's internet.

Given the way Chromium uses certificate pinning, a man in the middle would not have been able to deliver some other version of NaCl executable. It should be noted that locally stored root certificates for proxies and the like are not subject to pinning, though. It's a pretty far-fetched attack mechanism, since having access to install certificates locally would allow anything else to be installed at the same time. Being able to sign certificates for any site and have them accepted by all of the affected browsers would also seem to provide endless avenues of exploitation.

This incident is a little disheartening, overall. The web is a big, scary place these days; we depend on browsers that are working to protect their users. Undoubtedly Google doesn't see this executable download as a violation of that—rather it is probably seen as a nifty feature—but many outside the Googleplex quite reasonably disagree. As long as we have the source, and are vigilant about reviewing it, we can be reasonably assured of having browsers (and other programs) that do protect their users. That may, at some point, require a fork-and-rebrand effort for a browser or other open-source project if the organization developing it won't back down from some kind of anti-feature. Thankfully, that seems to be a problem for down the road—if ever.