Google Dismisses Chrome Browser Microphone Snooping Exploit

A researcher has released an exploit that abuses flaws he discovered in Chrome that could allow an attacker to snoop on phone calls or other conversations at your desktop, but Google says it's compliant with W3C

Google has shot down a researcher's claims that an exploit he posted online showing how an attacker could snoop on phone calls or other conversations on a user's machine constitutes a security flaw, maintaining that Chrome's speech-recognition feature complies with the W3C's specification.

Researcher Tal Ater, who stumbled across the issues when working on his JavaScript Speech Recognition library called annyang, says he reported the exploit to Google's security team on Sept. 13; six days later, Google engineers had suggested fixes for it. "On September 24, a patch which fixes the exploit was ready, and three days later my find was nominated for Chromium's Reward Panel (where prizes can go as high as $30,000.) Google's engineers, who've proven themselves to be just as talented as I imagined, were able to identify the problem and fix it in less than 2 weeks from my initial report," Ater wrote in a blog post this week exposing the exploit.

But Google never issued a patch. Ater says Chrome remains vulnerable and leaves users open to snooping attacks via malicious websites abusing the speech recognition/microphone feature. Meanwhile, Google maintains that the feature complies with the W3C specification for browsers and is safe.

"The security of our users is a top priority, and this feature was designed with security and privacy in mind. We've re-investigated, and this is not eligible for a reward since a user must first enable speech recognition for each site that requests it. The feature is in compliance with the current W3C specification," a Google spokesperson said.

The exploit requires that the user enable microphone use on a website, and most sites ask for permission for microphone activation. According to Ater, though, that can be abused.

"When you click the button to start or stop the speech recognition on the site, what you won't notice is that the site may have also opened another hidden popunder window. This window can wait until the main site is closed, and then start listening in without asking for permission. This can be done in a window that you never saw, never interacted with, and probably didn't even know was there," he said in his post. "To make matters worse, even if you do notice that window (which can be disguised as a common banner), Chrome does not show any visual indication that Speech Recognition is turned on in such windows -- only in regular Chrome tabs."

But a microphone indicator does show up in Chrome or in the URL bar of a pop-up window, and the latest version of Chrome does not allow a hidden pop-up Window, according to one security source who asked not to be identified.

Ater told Dark Reading that while Chrome does comply with new changes to the W3C's Web Speech API Spec, that specification is still not officially on the standards track. "However, the word 'spec' is quite misleading here, as it is currently not a W3C standard, nor is it on track to become one. Only late in 2014 is it scheduled to become a W3C recommendation," Ater said in an email interview.

"Thankfully, Google and Apple are not waiting for things to standardize before implementing it, and are continuously pushing the Web forward, experimenting with new technologies in their browsers, and helping shape the spec itself," he says. "But when you're so ahead of the bleeding edge, you can't fall back on the spec, and it is your responsibility to your users to make sure any security issues which are found in your software are handled promptly."

He says the bugs he found on their own may be relatively minor, but that doesn't mean they couldn't result in an attack. "But often the severity of a security breach is more then the sum of its parts. Its severity should be measured by the amount of damage a creative hacker can inflict with it, which is what I aimed to show in the video I sent Google," he says.

Ater says the changes that allow Speech Recognition in background tabs and windows are a step in the right direction for users, but only if the spec also addresses the security implications. And earlier this week, he joined the group that published the Web Speech API Specification, and hopes to "contribute a small part to fix this," he says.

Privacy Sensitivity
Ater's argument appears to be more about the W3C specification than Chrome, says Chris Wysopal, CTO of Veracode. "His beef is with the standard spec, that it's not making it clear enough to users that they are granting permission for this website to use the microphone forever," Wysopal says. "That probably [there] will be all kinds of tricky ways websites can hide that and have a window open so you might not notice what's going on."

In the post-NSA revelations world of heightened privacy concerns, Ater's exploit is yet another example of concerns about how much access users are granting to their machines as well as mobile apps. "This is just one of many problems we have with the idea that we're entering the realm of more privacy where we're granting devices access to pictures, cameras, phones, and GPS locations," Wysopal says. "Users are not really quite aware of how the website or app connecting back to the service is using this information. Is it collected all the time?

"I think this is the tip of the iceberg with the problem we are going to start to see more and more. We don't have a good paradigm for the user to understand [this]."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.
Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Published: 2015-03-31The build_index_from_tree function in index.py in Dulwich before 0.9.9 allows remote attackers to execute arbitrary code via a commit with a directory path starting with .git/, which is not properly handled when checking out a working tree.