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

5/11/2011
03:13 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Google, VUPEN Spar Over Chrome Hack

If bypass of Chrome's sandbox indeed used a new Flash vulnerability in the browser, then it's both a Flash bug and a Chrome hack, says security researcher Dan Kaminksy

The Google Chrome browser hack revealed this week could come down to a dispute over third-party software: A Google security expert says a zero-day flaw discovered by VUPEN Security researchers to bypass the browser's sandbox actually lies in Adobe Flash. But VUPEN isn't budging on its claims that its researchers successfully "owned" the browser software itself.

But for now, only VUPEN and its "three-letter" government agency customers know the details about the two zero-day vulnerabilities that VUPEN says it exploited and successfully used to bypass Chrome's sandbox and other security features.

"Nobody knows how we bypassed Google Chrome's sandbox except us and our customers, and any claim is a pure speculation," says Chaouki Bekrar, CEO and head of research at VUPEN. "We will not reveal the details on how we achieved the full compromise of Chrome and its sandbox. We can, however, say that we did use the default and built-in attack surface of the browser without using a Windows kernel vulnerability. All users of Chrome should be aware now that this browser can be fully hacked despite its famous sandbox and despite all the marketing that Google has been doing around its security."

Bekrar would neither confirm nor deny whether his firm found the bug in Chrome's Flash plug-in implementation, which comes with the browser. But he did say this when asked about it: "Google Chrome sandboxes all its default plug-ins; thus, exploiting a plug-in vulnerability is not enough to bypass the sandbox."

Google, meanwhile, is challenging VUPEN's claims of a bug in Chrome. Google security researcher Tavis Ormandy said in a Twitter post that "VUPEN misunderstood how sandboxing worked in chrome, and only had a flash bug."

A Google spokesperson said the Chrome team is still investigating VUPEN's claim that it hacked Chrome's famed sandbox feature. Chrome's sandbox, along with its use of Microsoft's DEP and ASLR technologies, thus far has made the browser relatively impenetrable to hackers.

Aside from a video and blog posting on the attack, VUPEN has kept details of the flaws and exploits closely held: As of this posting, Google hadn't received them. Bekrar did reveal yesterday in an interview that VUPEN employed one zero-day that's exploited inside the sandbox, and another that's executed outside of it. "The first one results from a memory corruption leading to the execution of the first payload at low-integrity level, inside the sandbox," he says. "A second payload is then used to exploit another vulnerability, which allows the bypass of the sandbox and execution of the final payload with medium-integrity level, outside the sandbox."

But tweets today from Google's Ormandy appear to point to Flash as containing a vulnerability, not Chrome.

So what gives?

Both VUPEN and Google are technically right, says security expert Dan Kaminsky, who has been analyzing VUPEN's public disclosure and the debate that unfolded on Twitter between the two companies today. "VUPEN didn't break the primary Chrome sandbox. It might have broken a secondary Flash sandbox. But at the end of the day, the [Chrome] browser got owned," Kaminsky says. "This is sort of a rare, nuanced situation where everyone is right."

Kaminsky applauds Google's efforts to lock down Chrome. He says the issue with the VUPEN research is that it goes back to the issue of using and keeping third-party software safe. "Everyone has been scratching their heads for years about what to do about insecure plug-ins," he says. Google took Flash code "in-house," for example and wrote a PDF parser for PDF plug-ins.

Google basically assumed the responsibility of keeping its browser users as safe as possible with Flash, Kaminsky says. "Chrome has to push an update of Flash ... because [of] the code they shipped that's buggy," he says. "If you ship it in your browser and it's on by default, it's your responsibility. Sometimes you're going to get burnt because of it."

Kaminsky says that because Flash "breaks" when placed in the browser's primary sandbox, it's not protected by it. "[Google is] still working on a version of Flash that doesn't break when put in the sandbox," he says.

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
Virginia a Hot Spot For Cybersecurity Jobs
Jai Vijayan, Contributing Writer,  10/9/2019
How to Think Like a Hacker
Dr. Giovanni Vigna, Chief Technology Officer at Lastline,  10/10/2019
7 SMB Security Tips That Will Keep Your Company Safe
Steve Zurier, Contributing Writer,  10/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-17660
PUBLISHED: 2019-10-16
A cross-site scripting (XSS) vulnerability in admin/translate/translateheader_view.php in LimeSurvey 3.19.1 and earlier allows remote attackers to inject arbitrary web script or HTML via the tolang parameter, as demonstrated by the index.php/admin/translate/sa/index/surveyid/336819/lang/ PATH_INFO.
CVE-2019-11281
PUBLISHED: 2019-10-16
Pivotal RabbitMQ, versions prior to v3.7.18, and RabbitMQ for PCF, versions 1.15.x prior to 1.15.13, versions 1.16.x prior to 1.16.6, and versions 1.17.x prior to 1.17.3, contain two components, the virtual host limits page, and the federation management UI, which do not properly sanitize user input...
CVE-2019-16521
PUBLISHED: 2019-10-16
The broken-link-checker plugin through 1.11.8 for WordPress (aka Broken Link Checker) is susceptible to Reflected XSS due to improper encoding and insertion of an HTTP GET parameter into HTML. The filter function on the page listing all detected broken links can be exploited by providing an XSS payl...
CVE-2019-16522
PUBLISHED: 2019-10-16
The eu-cookie-law plugin through 3.0.6 for WordPress (aka EU Cookie Law (GDPR)) is susceptible to Stored XSS due to improper encoding of several configuration options in the admin area and the displayed cookie consent message. This affects Font Color, Background Color, and the Disable Cookie text. A...
CVE-2019-16523
PUBLISHED: 2019-10-16
The events-manager plugin through 5.9.5 for WordPress (aka Events Manager) is susceptible to Stored XSS due to improper encoding and insertion of data provided to the attribute map_style of shortcodes (locations_map and events_map) provided by the plugin.