Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

1/23/2014
04:32 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

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 the Executive Editor of Dark Reading. 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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
44% of Security Threats Start in the Cloud
Kelly Sheridan, Staff Editor, Dark Reading,  2/19/2020
Zero-Factor Authentication: Owning Our Data
Nick Selby, Chief Security Officer at Paxos Trust Company,  2/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8818
PUBLISHED: 2020-02-25
An issue was discovered in the CardGate Payments plugin through 2.0.30 for Magento 2. Lack of origin authentication in the IPN callback processing function in Controller/Payment/Callback.php allows an attacker to remotely replace critical plugin settings (merchant ID, secret key, etc.) and therefore...
CVE-2020-8819
PUBLISHED: 2020-02-25
An issue was discovered in the CardGate Payments plugin through 3.1.15 for WooCommerce. Lack of origin authentication in the IPN callback processing function in cardgate/cardgate.php allows an attacker to remotely replace critical plugin settings (merchant ID, secret key, etc.) and therefore bypass ...
CVE-2020-9385
PUBLISHED: 2020-02-25
A NULL Pointer Dereference exists in libzint in Zint 2.7.1 because multiple + characters are mishandled in add_on in upcean.c, when called from eanx in upcean.c during EAN barcode generation.
CVE-2020-9382
PUBLISHED: 2020-02-24
An issue was discovered in the Widgets extension through 1.4.0 for MediaWiki. Improper title sanitization allowed for the execution of any wiki page as a widget (as defined by this extension) via MediaWiki's } parser function.
CVE-2020-1938
PUBLISHED: 2020-02-24
When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that ...