A French security research firm boasted today that it has discovered a two-step process for defeating Google Chrome‘s sandbox, the security technology designed to protect the browser from being compromised by previously unknown security flaws. Experts say the discovery, if true, marks the first time hackers have figured out a way around the vaunted security layer, and almost certainly will encourage attackers to devise similar methods of subverting this technology in Chrome and other widely used software.
In an advisory released today, VUPEN Security said: “We are (un)happy to announce that we have official Pwnd Google Chrome and its sandbox.” The post includes a video showing the exploitation of what VUPEN claims is a previously undocumented security hole in Chrome v.11.0.696.65 on Microsoft Windows 7 SP1 (x64).
“While Chrome has one of the most secure sandboxes and has always survived the Pwn2Own contest during the last three years, we have now uncovered a reliable way to execute arbitrary code on any installation of Chrome despite its sandbox, ASLR and DEP,” the advisory notes. ASLR and DEP are two of the key security defenses built into Windows Vista and Windows 7
Google spokesman Jay Nancarrow said the company was unable to verify VUPEN’s claims, because VUPEN hadn’t shared any information about their findings. “Should any modifications become necessary, users will be automatically updated to the latest version of Chrome,” Nancarrow wrote in an email to KrebsOnSecurity.
Chaouki Bekar, VUPEN’s CEO and head of research, confirmed that the company had no plans to share any details about their findings with Google, nor was it aware of any steps users could take to mitigate the threat from this attack.
“No, we did not alert Google as we only share our vulnerability research with our Government customers for defensive and offensive security,” Bekar wrote in response to an emailed request for comment. “Unfortunately, we are not aware of any mitigation to protect against these vulnerabilities.”
Jeremiah Grossman, a Web application security expert and chief technology officer for the security consultancy WhiteHat Security, called the news “quite serious.”
“We have governments competing for 0days, and we’re not even sure who the buyers are, maybe the US government didn’t get the 0day,” Grossman said “One way or the other, consumers are unprotected from an 0day we can’t really verify but probably exists. I think that’s quite serious.”
Bekar explained that the exploit they devised uses two distinct vulnerabilities: The first one results in a memory corruption and disclosure leading to the bypass of ASLR/DEP and execution of the first payload as low integrity level (inside the sandbox). 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).
Grossman said that even if VUPEN’s claims can be proven correct, he would still consider Chrome more secure by default than either Firefox or Internet Explorer. “As VUPEN’s research indicates, to exploit Chrome you have to have two vulnerabilities, not just one. With Firefox and IE, you just need one vulnerability in those browsers to compromise the machine.” Also, he said, Chrome applies security updates automatically, and aut0-patches third-party plug-ins like Flash, often days before Adobe releases the stand-alone patch for Flash.
According to the latest statistics from W3Schools.com, Chrome’s market share has been growing steadily over the past year, and now comprises about 25 percent; Internet Explorer’s market share has dropped below that of Chrome (24.3 percent), while Firefox commands nearly 43 percent market share. (At KrebsOnSecurity.com, the browser share breakdown is roughly 23 percent Chrome, 26 percent IE, and 39 percent Firefox).
It seems odd that VUPEN would brag about a flaw that it plans to sell to government clients for offensive purposes, since doing so might tip off potential targets to be extra cautious. This also raises the question of how long it will be before hackers figure out a way to defeat the sandbox technology surrounding Adobe’s Reader X, which the company said was based in part on Google’s research. Currently, there are several zero-day vulnerabilities that Adobe has put off patching in Reader X, out of an abundance of confidence in the ability of its sandbox technology to thwart these attacks.
Why is VUPEN providing such kind of reliable exploits to governments?
For the same reasons the arms industry supplies them with weapons.
I call BS!
They’re trying to get more money outta Google than Google normally pays out…
Sadly, they are not. They plan to make significantly more money from this than Google would be willing to pay – and they brag around to attract buyers and to make them more willing to pay. It’s not the first time they’ve done it. I can imagine that the Chinese government would be glad to spend something like $50,000 on an exclusive 0day like this.
“VUPEN … confirmed that the company had no plans to share any details about their findings with Google, nor was it aware of any steps … to mitigate the threat from this attack.” sounds like a lot of hypocrisy to me… Of course there is no mitigation if those who could mitigate aren’t given any details on the problem. This “Yadda yadda, I have a secret zero-day” is puerile behavior that I’d expect from some blackhat kid, but it certainly annoys me from an alleged security firm.
From Vupens home page:
“Exploits for Offensive Security
For offensive security. Get access to weaponized and highly sophisticated exploits specifically designed for LEA and Intelligence Agencies.”
It sounds like they are either into official/industrial black-hat stuff (as well as the more normal defensive stuff) or are trying to get into it.
It’d be interesting to see if they have any connections to the French government. I can’t really see Paris smiling on a French company selling exploits to Foreign governments unless they were kept informed and had some control.
They do restrict buyers to NATO, ANZUS or ASEAN signatories. While it seems likely they do have at least an informal arrangement with French Intelligence, it’s worth noting that plenty of exploits get sold to all comers by western citizens – albeit usually with a lot less fanfare.
Nice find. I didn’t both to look for something like that because most companies conceal such activities from the public. Here’s the link for other readers:
http://www.vupen.com/english/services/lea-index.php
It’s definitely more economical to sell to governments and black hat groups than Google. Many say it’s unethical and it may be, but capitalism follows the ethics of profit maximization. This means that the current economic incentives favor groups like VUPEN.
At this point in my research, I can’t say with any certainty that regulation, liability legislation, etc. could make a better situation. Even if a secure coding approach was mandated, the residual bugs in all legacy libraries and applications would invalidate the security of the new approach. If I figure something out, I’ll post it but right now I’m still lookin’.
Google is the computer world’s version of George Soros.
DEP and ASLR are useful techniques but adoption has been slow and patchy. See this post from taosecurity (mid-2010). http://bit.ly/mDTiPg
not sure things have improved much and it’s for sure that hackers are already working on ways to bypass memory based exploits.
nonetheless, seems like pretty big news if the chrome sandbox has a leak.
Leaving the only defense against this then to be blacklist all French sites? 🙂
As long as you assume VUPEN only sells to the French
Wasn’t HBGary Federal trying to do cool research like this?
HBGary was trying to much more offensive minded
This is exactly why I prefer to use third party solutions such DefenseWall and SandboxIE, neither of which are easily identified via the browser’s user agent.
i tend to agree.
when the sandbox is tightly coupled to the app it’s easy for the attacker to predict what sandbox s/he needs to escape from.
that holds for chrome, but also for adobe reader x and anything else that has a sandbox built-in.
use a separate sandbox and an attacker would need to perform a great deal more intelligence gathering to find out which sandbox s/he needs to escape. it’s not impossible for the attacker to do, but it certainly raises the bar.
+ 1 Thanks for more fully articulating the point I was a trying (however poorly) to make about the relative benefits of third party sandboxing apps.
Chrome is in fact one of several browsers that I utilize, but each Internet facing application on my system also runs in an “untrusted” state in a DefenseWall sandbox. So when I’m running Chrome, it’s like having a sandbox encapsulated in another sandbox. A site utilizing the VUPEN crafted exploit would MOST LIKELY fail because it wasn’t crafted to also defeat DefenseWall, nor could even identify DefenseWall, as it can Chrome.
Hi, TJ!
It’s possible to identify DefenseWall, running on a computer, under “untrusted” restrictions. But to bypass well-designed sandbox is quite expensive thing. I’m just curious, how many resources VUPEN has spent to find and exploit this vulnerability in the Chrom’s sandbox implementation?
Ilya,
Thanks for setting me straight about the ability to identify DefenseWall. Now I better go wipe the egg off my face.
Hi, Kurt!
There is more common way to bypass any sandbox security approach, wherever it is- it’s about to exploit a vulnerability into a trusted/system process or into the Windows kernel itself (but kernel RVA’s should not be required). But this requires high time and resources, rising the bar dramatically.
hi ilya,
i’ll have to take your word for it, though i’m not sure how a sandboxed process gets access to ‘trusted/system processes’ unless there’s a vulnerability in the sandbox itself.
i recall a lengthy discussion in which it became clear that you and i don’t necessarily see eye-to-eye on what should be called a sandbox, and i’m left to wonder if perhaps what you’re talking about here applies only to those things which you would call a sandbox and i would not.
Kurt, it’s quite simple- by using internal inter-process communications. LPC, for instance.
i guess i’m just thinking that in the process of containing the behaviour of things inside the sandbox, the behaviour you’re describing ought to be contained as well. if not then that strikes me as a vulnerability in the sandbox implementation.
Generally applications which run with reduced privileges need something to run with normal privileges. This something is often called a “broker”.
If you run Chrome, the main UI is the broker, it, probably runs with normal privileges, but the rendering processes which are responsible for actual page interaction are run with reduced privileges. They talk to the main UI (the “broker”) and it shows you the content. When you click, your click is sent by the broker to the reduced privilege renderer which enables the page to respond to your click.
More or less the same thing happens with Acrobat X, and Internet Explorer (PMIE).
The way this generally works is that channels are created by the broker and given to the reduced privilege application as part of the initial environment when it launches. The reduced privilege application can’t create such channels on its own once it’s alive.
The point is that to attack a system, evil web page must first attack the reduced privilege process, then having taken over that process, it must send data to the broker which exploits a bug in the broker’s handling of data from the reduced privilege process. That exploit enables the process to take over the broker which runs as a normal process. Once it controls a normal process, it can then do whatever it wants. For extra points it could try to exploit a bug in the OS in order to gain system privileges.
The good thing about brokers is that they have much smaller attack areas than either Browsers or OS’s (plus they’re new and designed from scratch solely for the purpose of protecting against attacks, instead of growing organically/chaotically). As such, they should with time become securer faster than either Browsers or OS’s.
Regarding brokers, IE has two in protected mode:
1. IEUser.exe to save files outside of low integrity folders
2. IEInstal.exe to allow the installation of Active-X controls
http://msdn.microsoft.com/en-us/library/bb250462(v=vs.85).aspx
It would be nice to have advanced options within IE enabling a user to disable brokers. A LIL download folder would be another good option that would be easy enough to create either in Local Low or elsewhere with the icacls command.
Ditto for Adobe X Reader and the Chrome browser.
Kurt, I strongly recommend you to read more about LPC mechanisms, what’s the purpose of it, why and how it’s working.
ah, sorry, an oversight on my part. perhaps i shouldn’t have commented at that late hour. i see now why a process inside the sandbox would need to communicate with processes (especially services) outside the sandbox – at least for the type of sandbox being discussed here.
“Bekar explained that the exploit they devised uses two distinct vulnerabilities: The first one results in a memory corruption and disclosure leading to the bypass of ASLR/DEP [..]”
If I’m reading this right, there are 3 bugs involved: memory corruption + info-leak (ASLR bypass) + sandbox escape.
It’s not true that to break IE you need just one vulnerability. It has Protected Mode (sandbox) and ASLR/DEP too, so just one vulnerability is not enough. During the last pwn2own the researcher how exploited IE had to use three different vulnerabilities to bypass all the security restritions.
Again, w3school is not reliable, as it gives statistics only to their website. Reliable browser statistics can be found here: http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0
Chrome and Firefox have the very very popular addons ‘NoScript’ and ‘Adblock’. Either of these is addons is likely to block the ‘hitslink’ tracking functions.
This means that hitslink.com is no more reliable than w3schools.
Add to this the fact that w3schools are more open about their issues (hitlinks don’t seem mention the problem at all) I would guess that w3schools is the more accurate.
Nevertheless, neither of these sets of statistics can really be used to prove more than generalisations. eg: Firefox and Chrome are very popular.
Plus there is always a compatibility risk with Firefox and Chrome when hitting an aspx page.
I’m using (on some of my machines) SRWare Iron browser (which is based on Google Chrome – Chromium engine). If the VUPEN claims are true, I guess there is a high probability to be affected by the same vulnerability as Google Chrome.
Almost certainly. Just because you (generic)’re using a derivative of an exploitable application doesn’t mean you’re somehow magically protected.
It’s incredibly rare that derivatives are more protected from such things than the original.
A derivative which has intentionally removed features (which might be exploited) could be immune to some attacks. However, typically most derivatives have a slower/delayed release cycle which means that while the main version of a product may get a fix within a couple of days, the derivative may be exploitable for weeks after the bug has been fixed.
Just be happy you’re on a Personal Computer and not a Mobile Phone. The update cycle on mobiles is generally much much worse.
Browser market share statistics from W3Schools.com do not represent broader usage, since most W3Schools.com visitors are designers and developers. Same for KrebsOnSecurity.com–the audience is not a random sample.
Sites for which I have access to stats show that Chrome has a 14% share, +/- 1%. This is not a random sample either, but demonstrates the differences between audiences.
QUOTE: >>
” Chaouki Bekar, VUPEN’s CEO and head of research, *** confirmed that the company had no plans to share any details about their findings with Google ***, nor was it aware of any steps users could take to mitigate the threat from this attack. ”
<< END QUOTE.
So, they are knowingly putting the public at large, at risk of harmful consequences = a Crime…
Doesn't this make VUPEN and its "CEO" – Mr. Chaouki Bekar, part of a criminal enterprise to be urgently investigated by the Gov't.?
This is a very serious Crime.
True, but can be also a simple bluff.
VUPEN should be shunned from the infosec community until they adopt a more responsible ethos.
VUPEN shouldn’t just be shunned, they shouldn’t be considered part of the infosec community in the first place.
if they’re not willing to help improve security then are they really a security company? i don’t think so.
Not to beat a dead horse so to speak, but this once again goes to Law #10 of the 10 Immutable Laws of Security:
Technology is not a panacea
No matter how sophisticated the hardware and software become, they’ll never replace common sense and sound security policies and practices.
In other words, just switching to using Chrome (or Firefox for that matter) in an attempt to thwart bad guys from trying to compromise your system is a false sense of security. Sure, they can provide a level of security on some level on their own, but the key is a multi-layered defense, of which one very important layer is the person behind the keyboard (if you know what I mean). 🙂 As an example, I have used Internet Explorer as my only browser for years without ever getting malware.
I would love to switch from Firefox to Chrome; however until Chrome (for Windows 7) stops using weak SSL encryption (128 bit RC4 on the Google Secure search page), then I cannot use it.
Compare this with Firefox (for Windows 7) which I’ve configured to use 256 bit AES encryption on the Google Secure search page.
Dont see why this is a problem for you. Encryption is usually the strongest link in the security chain & attackers rarely try to brute force or cryptanalyze sessions. Besides, a properly implemented RC4 cipher is as good as 128AES but faster & easier to implement due to simplicity. Dont get too worried bout crypto: most attacks sidestep crypto. Just pick a good algoritm, including RC4, and worry about wat they actually target.
i agree with you in theory, but i think it deserves mentioning that RC4 has been done poorly/wrong a number of times (so it’s perhaps not as simple as it may at first appear) in some fairly high profile applications – not the least of which being WEP.
i also think it deserves mentioning that while stream ciphers are ideal for data streams, other types of ciphers may be more ideal for other modes of data transfer.
Nick P/Kurt
I am no expert on encryption, so I thank you for your comments, even though I didn’t really understand everything you said.
Do you really think that RC4 128 bit encryption is strong enough to prevent snooping, say, by an ISP?
Do you also believe that Chrome is more secure than Firefox because of the sandboxing technology?
truthfully, i’m no expert on encryption either, so take my answers with a grain of salt.
“Do you really think that RC4 128 bit encryption is strong enough to prevent snooping, say, by an ISP?”
although i’d be more comfortable with something other than RC4, i think it *could* be strong enough that the ISP couldn’t/wouldn’t break it.
that isn’t the same as saying it’s strong enough to prevent snooping by an ISP, however. an ISP may legitimately be in a man-in-the-middle sort of position, and with all the questions recently about the how far you can trust a signature from a certificate authority it’s not inconceivable that an ISP would be able to leverage their position to mount an actual man-in-the-middle attack on an SSL connection.
if you don’t trust the machines you’re connecting to, i’m not sure SSL is going to be able to save you.
“Do you also believe that Chrome is more secure than Firefox because of the sandboxing technology?”
for reasons i’ve mentioned in another comment here, i prefer not to rely on the built-in sandbox and instead use both browsers inside a separate sandbox. chrome might be more secure because of it’s sandbox, but a built-in sandbox is not an optimal sandbox deployment in my opinion.
@Sean:
The browser has very little to do with the encryption algorithm used. The algorithm is chosen based on the SSL cipher preferences of both the server and the client. On my machine, both FF and Chrome use RC4 on Google websites.
SSL/TLS is a standard — it is implemented the same across all browsers. The way it works is if the server has RC4 as its first preference and your browser supports RC4, then RC4 will probably be used. So, it really depends more on the server than the client. The only way to force AES would be to blacklist RC4 in the browser config settings.
That said, there is nothing wrong with RC4. It is generally faster than other alternatives (as it is a stream cipher.) The implementation in WEP was a WEP flaw and not really an RC4 flaw.
Bottom line: Chrome is not “forcing” RC4 on you. It’s more up to the server you’re connected to.
Meanwhile, over on Darknet they’re openly doubting that VUPEN has actually escaped Chrome’s sandbox. They claim to, but for murky reasons that are foggy to understand, they don’t want to demonstrate it.
The suspicion is that they haven’t really done it, but it’s great PR for their prowess as so-called malware experts. And you’ve got to admit, it’s put them on the map. After all, in the PR biz, ALL name recognition is good name recognition.
From the blog article:
“It seems odd that VUPEN would brag about a flaw that it plans to sell to government clients for offensive purposes, since doing so might tip off potential targets to be extra cautious.
Note the timeline:
5/9/2011 – VUPEN releases Google Chrome browser advisory
5/10-11/2011 – Google I/O takes place
Coincidence?
Back to the technical side, there are some reports today that Flash may have been a weak link as it is embedded in Chrome. And while Google is in the process of sandboxing Flash within Chrome, it has only been partially implemented to date.
This begs the question, would disallowing plug-ins in the Chrome browser content settings have prevented this exploit?
Just one small thought, for what they state the “trick” work only on Windows machines, so no problem on Linux and Unix OS powered computers…
So at this point, stupid question…
Is it possible that the game is to promote other Operative Systems? I mean, no disclosure, no informations, nothin! Just a Video. They Claim: Google Chrome is the Hardest to Hack… mmm…
[…]Grossman said that even if VUPEN’s claims can be proven correct, he would still consider Chrome more secure by default than either Firefox or Internet Explorer.[…]
Kinda strange, sounds like advertisement…