Vulnerabilities / Threats
1/22/2014
09:53 AM
Connect Directly
LinkedIn
Twitter
Google+
RSS
E-Mail
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
JosephM975
50%
50%
JosephM975,
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
50%
50%
Thomas Claburn,
User Rank: Moderator
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.
JosephM975
50%
50%
JosephM975,
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
100%
0%
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.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3352
Published: 2014-08-30
Cisco Intelligent Automation for Cloud (aka Cisco Cloud Portal) 2008.3_SP9 and earlier does not properly consider whether a session is a problematic NULL session, which allows remote attackers to obtain sensitive information via crafted packets, related to an "iFrame vulnerability," aka Bug ID CSCuh...

CVE-2014-3908
Published: 2014-08-30
The Amazon.com Kindle application before 4.5.0 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

CVE-2010-5110
Published: 2014-08-29
DCTStream.cc in Poppler before 0.13.3 allows remote attackers to cause a denial of service (crash) via a crafted PDF file.

CVE-2012-1503
Published: 2014-08-29
Cross-site scripting (XSS) vulnerability in Six Apart (formerly Six Apart KK) Movable Type (MT) Pro 5.13 allows remote attackers to inject arbitrary web script or HTML via the comment section.

CVE-2013-5467
Published: 2014-08-29
Monitoring Agent for UNIX Logs 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP09, and 6.2.3 through FP04 and Monitoring Server (ms) and Shared Libraries (ax) 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP08, 6.2.3 through FP01, and 6.3.0 through FP01 in IBM Tivoli Monitoring (ITM)...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.