Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
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
4 Min Read
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.
About the Author(s)
Kelly Jackson Higgins is the Editor-in-Chief 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 Magazine, Virginia Business magazine, and other major media properties. Jackson Higgins was recently selected as one of the Top 10 Cybersecurity Journalists in the US, and named as one of Folio's 2019 Top Women in Media. She began her career as a sports writer in the Washington, DC metropolitan area, and earned her BA at William & Mary. Follow her on Twitter @kjhiggins.
You May Also Like
Unbiased Testing. Unbeatable ResultsFeb 22, 2024
Unbiased Testing. Unbeatable ResultsFeb 22, 2024
Your Everywhere Security guide: Four steps to stop cyberattacksFeb 27, 2024
Your Everywhere Security Guide: 4 Steps to Stop CyberattacksFeb 27, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
A screen displaying many different types of charts and graphs to show what data is being analyzed.Cybersecurity Analytics