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.