Break Google Chrome in six steps

Break Google Chrome in six steps

Browsers are a really nice target for attackers of all stripes and skill levels. But, unless you're a savant or have just landed here from the future, you may want to take a pass on going after Google Chrome, judging by the insane level of effort and skill that an anonymous security researcher had to deploy in order to compromise Chrome during the company's Pwnium contest in March.


The researcher who received one of two $60,000 rewards handed out by Google for full sandbox escapes and compromises of Chrome during the contest used the alias Pinkie Pie. At the time that his accomplishment was announced during the CanSecWest conference in March, Google officials did not specify exactly how the researcher had been able to break Chrome's many layers of security, but just said that he had used multiple bugs to do it.


Now, Google security researchers have revealed the method and techniques that Pinkie Pie used, and if anything, the whole story is even more impressive than observers had thought at the time of the contest. Pinkie Pie used a total of six vulnerabilities in various components of Chrome, chaining them together in a long sequence that eventually enabled him to break out of the Chrome sandbox and completely compromise the browser.
The first part of this long process was exploiting a bug in the way that Chrome uses pre-rendering to handle Native Client content on Web pages.  


"Prerendering is a performance optimization that lets a site provide hints for Chrome to fetch and render a page before the user navigates to it, making page loads seem instantaneous. To avoid sound and other nuisances from preloaded pages, the prerenderer blocks plug-ins from running until the user chooses to navigate to the page. Pinkie discovered that navigating to a pre-rendered page would inadvertently run all plug-ins—even Native Client plug-ins, which are otherwise permitted only for installed extensions and apps," Google's Jorge Lucangeli Obes and Justin Schuh said in an analysis of the attack.


"Of course, getting a Native Client plug-in to execute doesn’t buy much, because the Native Client process’ sandbox is even more restrictive than Chrome’s sandbox for HTML content. What Native Client does provide, however, is a low-level interface to the GPU command buffers, which are used to communicate accelerated graphics operations to the GPU process. This allowed Pinkie to craft a special command buffer to exploit the following integer underflow bug (117656) in the GPU command decoding."


Once he had control of the GPU process, Pinkie Pie needed to find a target for his overwrite. He need the target to be something that was worth his effort to modify, so he went after the GPU buckets.


"For this, he used the GPU buckets, which are another IPC primitive exposed from the GPU process to the Native Client process. The buckets are implemented as a tree structure, with the first eight bytes containing pointers to other nodes in the tree. By overwriting the first eight bytes of a bucket, Pinkie was able to point it to a fake tree structure he created in one of his transfer buffers. Using that fake tree, Pinkie could read and write arbitrary addresses in the GPU process. Combined with some predictable addresses in Windows, this allowed him to build a ROP chain and execute arbitrary code inside the GPU process," the Google analysis said.
"The GPU process is still sandboxed well below a normal user, but it’s not as strongly sandboxed as the Native Client process or the HTML renderer. It has some rights, such as the ability to enumerate and connect to the named pipes used by Chrome’s IPC layer. Normally this wouldn’t be an issue, but Pinkie found that there’s a brief window after Chrome spawns a new renderer where the GPU process could see the renderer’s IPC channel and connect to it first, allowing the GPU process to impersonate the renderer (bug 117627)."


From there, Pinkie was able to find another bug in one of Chrome's renderers that gave him the ability to access a privileged renderer through an unprivileged one, something that should not have been possible. He used that flaw to gain access to the extension manager inside the browser, and then impersonate that process. Then came the hard part: breaking out of the Chrome sandbox.


"Once he was impersonating the extensions manager, Pinkie used two more bugs to finally break out of the sandbox. The first bug (117715) allowed him to specify a load path for an extension from the extension manager’s renderer, something only the browser should be allowed to do. The second bug (117736) was a failure to prompt for confirmation prior to installing an unpacked NPAPI plug-in extension. With these two bugs Pinkie was able to install and run his own NPAPI plug-in that executed outside the sandbox at full user privilege," Google said.


Regards,
Hardeep Singh