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

09:53 AM
Connect Directly

Google Chrome Allows Eavesdropping, Researcher Claims

Google doesn't recognize the browser behavior as a security issue.

The way that Google Chrome allows web apps to access microphones in computers is being described by a web developer as a security flaw.

Tal Ater, a programmer based in Israel, on Tuesday published details about the issue on his website. He says he has been working with Google engineers since first reporting the issue on Sept. 13, 2013.

Google doesn't recognize the issue, demonstrated in this YouTube video, as a valid exploit, and insists Chrome is safe and performing as expected.

Chrome provides access to a computer's microphone (if one exists) on the host device through the Web Speech API. After seeking permission, Google's browser allows users to click on the microphone icon in the Google Search input box to listen for spoken words that can be recognized by the company's speech-to-text algorithms and turned into text-based search queries.

[Are you still using one of the 25 least secure passwords? See 'Password' No Longer Worst Password.]

Two months ago, Google also released a Chrome extension that allows "hotwording" -- having the host device listen constantly for a key phrase like "ok Google," in order to automatically interpret whatever words follow as a voice command.

But in pushing the boundaries of browser development, Google may have provided malicious hackers with an opportunity to spy on the unsuspecting, Ater claims.

Google's security team developed a fix to the identified vulnerabilities within two weeks, Ater says, but has been waiting for the W3C, the web standards body, to agree on the best approach to fix the flaw.

Google in an email statement put it another way: "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 still believe there is no immediate threat, since a user must first enable speech recognition for each site that requests it. The feature is in compliance with the current W3C standard, and we continue to work on improvements."

Ater explained in a previous email that Chrome does not comply with the W3C's unfinished specification for Web Speech, which states that code implementing the Web Speech API should "abort an active speech input session if the webpage lost input focus to another window or to another tab within the same user agent," in order to reduce the chance of allowing websites to record without the user's knowledge.

Tal Ater's YouTube video demonstrates what he says is a flaw in Chrome.
Tal Ater's YouTube video demonstrates what he says is a flaw in Chrome.

But that recommendation was struck from the specification last November. The Web Speech API errata calls for the deletion that very sentence. This appears to make the scenario depicted in Ater's video -- in which a hidden pop-under window continues recording surreptitiously after the user has granted recording permission and then navigated to another website -- acceptable, at least from a standards perspective.

Ater says he agrees that it was a good idea to remove the restriction because there are times when one might want a background window active during speech recognition. He also agrees that speech recognition permission should be allowed to persist across sessions. 

"The problem is that the current implementation allows turning on speech recognition in a background window or tab that the user has never interacted with and may not be aware is there," Ater said. "Add to this the fact that there is no visual indication in pop-up windows for speech recognition being turned on, and you have a perfect combination of little bugs and issues coming together to create an exploit that is more than the sum of its parts."

Such behavior appears to allow Chrome to be turned into a covert listening device, but because Google has addressed some of these issues, it's not clear how easy abuse might be. Ater has posted sample exploit code in a Github repository.

"I think the severity of this exploit should be measured by how it can be used to create something which can affect a user's privacy, and not by the severity of each of its small parts," said Ater.

The Chromium team is working on at least one other microphone-related security issue.

None of this is entirely surprising. Microphones have represented a security vulnerability for more or less as long as they've been around, but they're even more of a potential threat in an era of mobile, network-connected devices. In 2008, security researchers identified a flaw in Adobe Flash that allowed webcams to be hijacked for surreptitious surveillance. A related Flash for Chrome vulnerability surfaced last year. Also last year, Cisco published a warning of an exploit that could turn one of its IP phones into a surreptitious listening device.

Back in the 1980s and for years after that, Lucasfilm's acoustics certification group THX ran thundering trailers in movie theaters that declared "The audience is listening." Today, the computers are listening, quietly but attentively.

Thomas Claburn is editor-at-large for InformationWeek. He has been writing about business and technology since 1996, for publications such as New Architect, PC Computing, InformationWeek, Salon, Wired, and Ziff Davis Smart Business. Before that, he worked in film and television. He's the author of a science fiction novel, Reflecting Fires, and his mobile game Blocfall Free is available for iOS, Android, and Kindle Fire.

InformationWeek Conference is an exclusive two-day event taking place at Interop where you will join fellow technology leaders and CIOs for a packed schedule with learning, information sharing, professional networking, and celebration. Come learn from each other and honor the nation's leading digital businesses at our InformationWeek Elite 100 Awards Ceremony and Gala. You can find out more information and register here. In Las Vegas, March 31 to April 1, 2014.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
1/23/2014 | 6:43:07 PM
Re: Taking too long.
The plugin's security settings are user granted, look at the source code. It takes very little permission to do this and I can't believe it'ts not considered malware. I write in Java and in C# and in all web languaes and this is something that with a little bit of added logic we can recognize certain strings, especially if these strings contain sensitive information and patterns for example long number combinations (typical of credit cards), words and numbers (typical password combinations), or any other 'keyword' or combowords we want to look for. The exploit is simple in that once you grant the browser permission to access your microphone (example "Okay Google!" voice command on google.com), it will continue to runt he script once downloaded to your internet cache and will run as long as chrome is still being executed. You should not base your misleading article title on the video alone, you need to support your statement with technological evidence, as I can support that this exploit is real since I downloaded the source code and tested it on my servers myself. 


All it needs is one-time permission to run 'in the background' during your session on Chrome. This is the same nature as malware and other viruses in how this can be executed.

This exploit only works on Chrome for windows and MAC OS.
Thomas Claburn
Thomas Claburn,
User Rank: Ninja
1/23/2014 | 6:20:20 PM
Re: Taking too long.
The article says "claims" because the video isn't definitive proof the exploit works, particularly when Google is saying it's not an issue. I just am not enough of a Javascript expert to state categorically that the exploit works or doesn't. It may work in some circumstances but not in others. It may depend on the plug-ins and security settings of the user's browser. Security is best left to experts.
User Rank: Apprentice
1/23/2014 | 5:01:45 PM
Re: Taking too long.
Isn't it funny how this article (#2 on the search ranking right now) states that the "researcher claims" this when there is a full source code exploit written to show the bug using chrome. I downloaded the source code and analysed it and it is very tiny and takes very little code to to this. Anyone can embed this code on their websites and create a cached copy on their server, I tested it on mine. THIS IS REAL
Kristin Burnham
Kristin Burnham,
User Rank: Apprentice
1/22/2014 | 8:10:41 PM
Taking too long.
The possibility of listening via your microphone is creepy -- and it's disconcerting that it's taking so long to fix.
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Google's new See No Evil policy......
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-18
RIOT-OS 2021.01 before commit 44741ff99f7a71df45420635b238b9c22093647a contains a buffer overflow which could allow attackers to obtain sensitive information.
PUBLISHED: 2021-06-18
SerenityOS contains a buffer overflow in the set_range test in TestBitmap which could allow attackers to obtain sensitive information.
PUBLISHED: 2021-06-18
SerenityOS in test-crypto.cpp contains a stack buffer overflow which could allow attackers to obtain sensitive information.
PUBLISHED: 2021-06-18
SerenityOS before commit 3844e8569689dd476064a0759d704bc64fb3ca2c contains a directory traversal vulnerability in tar/unzip that may lead to command execution or privilege escalation.
PUBLISHED: 2021-06-18
RIOT-OS 2021.01 before commit 85da504d2dc30188b89f44c3276fc5a25b31251f contains a buffer overflow which could allow attackers to obtain sensitive information.