Welcome Guest. | Log In | Register | Membership Benefits

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

May 11, 2011 | 03:13 PM | 

By Kelly Jackson Higgins
Dark Reading
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.



Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dark Reading encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dark Reading moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Dark Reading further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS



Advanced Threats Reports

report How Did They Get In? A Guide to Tracking Down The Source of an APT
If you think that your organization hasn't been affected by an advanced persistent threat, you probably haven't looked hard enough. Identifying that your organization is under attack is difficult enough; determining the scope of infiltration and damage presents a whole new level of challenge. To effectively protect against APTs, security pros will need to employ an arsenal of tools in a coordinated fashion, as well as develop new understandings of and approaches to system and data exploits. Here's a short and simple guide to this challenge.

report Detecting and Defending Against Advanced Persistent Threats
APTs are a growing problem for enterprises big and small. Protecting your organization from these targeted threats requires constant vigilance, ongoing employee training and a concerted effort to align security systems to address every phase of an APT. Companies also need to develop a remediation and response plan if, despite best efforts, defenses are breached.

report Smarter, Stealthier, Sneakier Malware
Increasingly sophisticated and targeted attacks are making it more difficult for organizations to detect and defend against the latest malware. In this compendium of recent coverage from Dark Reading, you?ll get a look at some of the newest -- and most dangerous -- malware on the Web, and what you can do to stop it.

Other reports from the Advanced Threats Tech Center:

Related Content

MOBILE SECURITY - Mapping an Ecosystem of Risk
This white paper highlights the various considerations for defending mobile applications-from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.

Software Security Delivered in the Cloud
This Solution Guide details the automated, turnkey service that requires no special security assessment expertise. It details HP's market-leading static and dynamic analysis technologies that help organizations worldwide gain insight into the security state of their essential business applications.

SANS Mobility/BYOD Security Survey
This survey, which includes input from more than 500 IT professionals, explores how organizations are managing risk around their end user mobile devices as well as what level of policies and controls enterprises have around mobile usage.

Expert Guide to Application Security - Real-time Hybrid Analysis
Explore the next generation of hybrid security analysis - what it is, how it works, and its benefits. This white paper details how hybrid application security enables organizations to resolve critical software security issues faster and at a lower cost than any other available technology.

A Mainstay Partners Study: Does Application Security Pay?
Measuring the Business Impact of Software Security Assurance Solutions: a study of 17 organizations that implemented solutions from Fortify Software, combining industry research and benchmark analysis to identify, qualify, and quantify the full range of benefits seen from their SSA investments.




Featured Webcasts
Featured Whitepapers
Featured Reports