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

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 Senior 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 Magazine, ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web