Just over two months ago, Chrome sponsored the Pwnium browser hacking competition. We had two fantastic submissions, and successfully blocked both exploits within 24 hours of their unveiling. Today, we’d like to offer an inside look into the exploit submitted by Pinkie Pie.

So, how does one get full remote code execution in Chrome? In the case of Pinkie Pie’s exploit, it took a chain of six different bugs in order to successfully break out of the Chrome sandbox.

Pinkie’s first bug (117620) used Chrome’s prerendering feature to load a Native Client module on a web page. 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.

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:

The issue here is that if size_of_buffer is smaller than sizeof(uint32), the result would be a huge value, which was then used as input to the following function:

This calculation then overflowed and made the result of this function zero, instead of a value at least equal to sizeof(uint32). Using this, Pinkie was able to write eight bytes of his choice past the end of his buffer. The buffer in this case is one of the GPU transfer buffers, which are mapped in both processes’ address spaces and used to transfer data between the Native Client and GPU processes. The Windows allocator places the buffers at relatively predictable locations; and the Native Client process can directly control their size as well as certain object allocation ordering. So, this afforded quite a bit of control over exactly where an overwrite would occur in the GPU process.

The next thing Pinkie needed was a target that met two criteria: it had to be positioned within range of his overwrite, and the first eight bytes needed to be something worth changing. 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 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).

Even though Chrome’s renderers execute inside a stricter sandbox than the GPU process, there is a special class of renderers that have IPC interfaces with elevated permissions. These renderers are not supposed to be navigable by web content, and are used for things like extensions and settings pages. However, Pinkie found another bug (117417) that allowed an unprivileged renderer to trigger a navigation to one of these privileged renderers, and used it to launch the extension manager. So, all he had to do was jump on the extension manager’s IPC channel before it had a chance to connect.

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.

So, that’s the long and impressive path Pinkie Pie took to crack Chrome. All the referenced bugs were fixed some time ago, but some are still restricted to ensure our users and Chromium embedders have a chance to update. However, we’ve included links so when we do make the bugs public, anyone can investigate in more detail.

In an upcoming post, we’ll explain the details of Sergey Glazunov’s exploit, which relied on roughly 10 distinct bugs. While these issues are already fixed in Chrome, some of them impact a much broader array of products from a range of companies. So, we won’t be posting that part until we’re comfortable that all affected products have had an adequate time to push fixes to their users.

The Dev channel has been updated to 21.0.1145.0 for Windows, Mac and Linux platforms

All

• Updated V8 - 3.11.3.0
• Allow certain unused renderer processes to exit before the tab is closed. (Issue: 126333)  

• Fix password autofill to work again for Incognito windows (Issue: 117720)

• Prevent an infinite loop inside SSLClientSocketNSS::OnSendComplete. This has been observed in Chrome OS, but could also happen on other platforms. (Issue: 127822)

Known Issues

• In bookmark bubble unable to edit the name and select the sub folder from drop down (Issue: 128612)

More details about additional changes are available in the svn log of all revisions.

Chrome: One of the best features in the search engine DuckDuckGo is the instant answers shown at the top of the results page. If you find yourself more attached to Google for web searches, but want the instant answer feature, DuckDuckGo Zero-Click Info is a Chrome extension that stuffs those results right in your Google searches.More »

According to digital analytics site StatCounter, Google Chrome has passed Internet Explorer as the most popular web browser with 31.88% of the world's web traffic. Internet Explorer wasn't far behind coming in at a close second with 31.47%.More »

Chrome: Prefer Google's search but wish you had Bing's beautiful daily images? With the "Bing wallpaper for Google homepage" Chrome extension, you can set Bing's wallpaper to automatically load on your Google homepage. The extension offers different themes and loading settings. More »

This release contains stability improvements and bug fixes.

Last year we proposed the Web Intents API to help web applications integrate with one another with minimal effort. We've now enabled an experimental version of the API in the most recent stable version of Chrome, to gather feedback from the web community and shape the future of the Web Intents API.

This prototype version of Web Intents makes it easier for developers to try out the API and experience its benefits first hand:

• Developers who build client apps will be able to easily include functionality from other web services (e.g., photo editing). 
• Developers creating those services will no longer need to invest time and resources to negotiate and build hardcoded integrations - they can just focus on offering a great quality product with the integration facilitated by the API. 

In addition, this implementation of Web Intents can help the design discussions in the W3C web intents open standards list. After all, it's impossible to build a complex API—especially one that requires an ecosystem of apps—without feedback from web developers using it in the wild.

We expect that Web Intents will evolve significantly, potentially in backwards-incompatible ways, as feedback from real world usage trickles in. Because of its experimental status, the current live version is prefixed and only allows applications to register as services in their Chrome Web Store app manifest.

Once the API is stable, we plan to remove this restriction.

To learn more on how to use the experimental Web Intents API check out the Web Developers' Guide to Web Intents in Chrome. If you choose to experiment with Web Intents, be sure to follow our discussion group, where we'll announce any impending breaking changes in Chrome's implementation.

The Dev channel has been updated to 20.0.1132.7 (Platform versions: 2268.9.0) for Chromebooks (Acer AC700 , Samsung Series 5, and Cr-48).

This build contains a number of new features, as well as security & stability improvements. Some highlights of these changes are:

Macquarie Equities Research released a report stating that Google’s Chrome browser might be coming to iOS device. The report does not state when it might arrive on the Apple’s app store, however, it states that  it could be as soon as Q2 of 2012 and if it doesn’t land on the app store by that time, it is definitely arriving by the end of this year.

As much as we would like to see the Chrome browser on iOS devices — iPhone, iPad, and iPod Touch, Apple doesn’t allow third party browser app to be set as a default app for the device which limits the usability of the app. For example, any links within an email, text messages will open on default browser (Safari) on any iOS devices.

Chrome browser on desktop is highly successful browser with about 18.57% of browser market share falling only slightly behind Mozilla Firefox. Google, also, recently released Chrome Beta for its own mobile operating system, Android. With the release of Chrome on iOS Google also might be able to get away with the huge chunk of money it spends on Apple for Google search on Safari browser. With Chrome browser, all the money that it will earn from the search, Google will be able to keep them with themselves.

However, we do not think Chrome for iOS will make it big for a simple reason that Apple does not allow third party apps to be set as default browser.

What timing. I posted my iPad for sale on Craigslist over the weekend -- and two people are jockeying to get ahead of the other to buy it today. But I'm suddenly unsure about selling, after seeing a Macquarie Capital report claiming that Chrome will come to iOS as early as this quarter. Hot damn!

I rarely make decisions based on rumors, nor should you. Besides, the "timing is unclear, but it could be as soon as Q2 and is very likely to be a 2012 event", according to Macquarie Capital. "Could" be this quarter and "likely" this year stink of pure speculation -- or big back door should there be no Chrome for iOS this year. In the end, I'll likely sell the iPad, but must convey this: Chrome would be a very good reason to buy an iOS device but be akin to Google cutting off one limb to save another.

Shine That Tablet's Chrome

Yesterday, Ian Betteridge and I bantered back and forth about Chrome and iOS on Google Plus. He called Google services on Apple devices a "pretty good experience", to which I responded: "I would agree about the Google ecosystem with iPhone (and iPad) if Chrome was option. That's the deal breaker for me, sadly. I'm seriously thinking about selling my iPad, for that reason -- and another: Galaxy Nexus is tablet enough for me, so far".

As expressed last week, "You can have iPhone 4S, I'll take Galaxy Nexus". But there's more. I find the Google and Samsung branded smartphone good enough replacement for my iPad, too. Chrome for Android is one reason, Galaxy Nexus' super sharp, 4.65-inch, 1280 x 800 resolution screen is the other. Repeating a sentiment from my Galaxy Nexus HSPA+ review: I'd by the phone just for Chrome, which currently is only available for Android 4 "Ice Cream Sandwich", in beta.

Presumably, Chrome would be available for the newest iOS version, which means broader distribution than Android, since Apple doesn't have the same fragmentation problem. Based on number of devices accessing Google Play during the previous 14 days, Ice Cream Sandwich accounted for just 4.9 percent of the Android install base on May 1. Chrome has limited reach at best on Android, while distribution could be enormous on iOS, assuming people using the browser on the desktop go mobile, too. There, Chrome is third-most used browser and closes on Firefox, according to Net Applications.

Chrome is a huge improvement over the stock Android browser. It's fast and flows, but sync capabilities, which include active tabs on the desktop, really stand out. Last week's huge Google+ for iPhone update shows that the search and information giant can deliver exceptional user experiences on iOS. Why shouldn't Chrome be same?

A TACtical Decision

The problem: Chrome for iOS, particularly iPad, removes an important reason to choose Android tablets over Apple's. Google gains in one area, while giving up somewhere else. If Google offered Chrome for iOS right now, I'd keep my iPad. How many other people considering Apple's tablet would choose it over an Android because of Chrome? You can help answer that question by taking our poll.

In April, with considerably smaller install base, iPad took decisive mobile browser usage share lead from iPhone, according to NetApps. More broadly, in the mobile device category, Safari has 63.84 percent usage share, compared to 18.87 percent for Chrome. Google's browser could make usage share leaps competing alongside Safari on iOS devices. The cloud-connected device era is all about mobile. Google should want Chrome on market-leading devices like iPad.

Then there are traffic acquisitions costs, which eat into Google search margins. Macquarie Capital: "If GOOG gains market share, it could reduce our estimate for Google.com TAC meaningfully". Google pays Apple to compete with Android -- and Chrome, for that matter -- via Safari's search bar. Google's TAC goes down when people use Chrome.

Something else: Google services have a cloudy future on Apple devices. There already are rumors Apple will ditch Google Maps for a home-grown option in iOS 6. I expect to see a Siri search service someday replace Google. Chrome for iOS would be an important anchor for Google services as Apple offers more of its own from the cloud.

Even then, Chrome faces hurdles placed by Apple. Based on the browsers currently available for iOS, Safari is default for mail and other services. So Chrome would be at disadvantage, as long as Apple only allows Safari to be default. However, surely Chrome could be default for Google services -- gulp, right?

From that viewpoint, Chrome will always be better on Android. That said, Chrome on iOS ought to be pretty good, and if Google is going to feed the hand that bites it, better to extend existing services rather than pay TAC to Apple.

My question for you: Would you use Chrome over Safari on iPad or iPhone? Please answer the question below and take our poll above.

Business Insider reports on a new research note from Macquarie analyst Ben Schacter, who claims that Google is working to bring a version of its Chrome browser to iOS devices. According to the report, Apple "may already be reviewing" the app, which could debut before the end of the quarter.

Google Chrome browser for Android

Google currently splits ad revenue share with Apple for Google searches performed through Safari, a deal that currently sees Google paying Apple roughly $1 billion per year. With a potential Chrome browser for iOS leading to Google keeping all revenue for searches through the browser for itself, Google could see a significant financial benefit if it can achieve a substantial user base on iOS.

The problem for Google is that Apple does not make it convenient for users to take advantage of third-party browsers, with Safari alternatives like Opera and Dolphin representing only tiny fractions of iOS browser share. Systemwide calls for browser actions throughout iOS apps are linked to Safari, meaning that users have to take extra steps to use a different browser, with the inconvenience leading the vast majority of users to simply use Safari for their iOS browsing needs.

According to a note published by Macquarie Equities Research, Google is working on an iPhone and iPad version of its Chrome browser, slated for launch sometime this year.More »

• [112983] Low CVE-2011-3083: Browser crash with video + FTP. Credit to Aki Helin of OUSPG.
• [113496] Low CVE-2011-3084: Load links from internal pages in their own process. Credit to Brett Wilson of the Chromium development community.
• [118374] Medium CVE-2011-3085: UI corruption with long autofilled values. Credit to “psaldorn”.
• [$1000] [118642] High CVE-2011-3086: Use-after-free with style element. Credit to Arthur Gerkis.
• [118664] Low CVE-2011-3087: Incorrect window navigation. Credit to Charlie Reis of the Chromium development community.
• [$500] [120648] Medium CVE-2011-3088: Out-of-bounds read in hairline drawing. Credit to Aki Helin of OUSPG.
• [$1000] [120711] High CVE-2011-3089: Use-after-free in table handling. Credit to miaubiz.
• [$500] [121223] Medium CVE-2011-3090: Race condition with workers. Credit to Arthur Gerkis.
• [121734] High CVE-2011-3091: Use-after-free with indexed DB. Credit to Google Chrome Security Team (Inferno).
• [$1000] [122337] High CVE-2011-3092: Invalid write in v8 regex. Credit to Christian Holler.
• [$500] [122585] Medium CVE-2011-3093: Out-of-bounds read in glyph handling. Credit to miaubiz.
• [122586] Medium CVE-2011-3094: Out-of-bounds read in Tibetan handling. Credit to miaubiz.
• [$1000] [123481] High CVE-2011-3095: Out-of-bounds write in OGG container. Credit to Hannu Heikkinen.
• [Linux only] [123530] Low CVE-2011-3096: Use-after-free in GTK omnibox handling. Credit to Arthur Gerkis.
• [123733] [124182] High CVE-2011-3097: Out-of-bounds write in sampled functions with PDF. Credit to Kostya Serebryany of Google and Evgeniy Stepanov of Google.
• [Windows only] [124216] Low CVE-2011-3098: Bad search path for Windows Media Player plug-in. Credit to Haifei Li of Microsoft and MSVR (MSVR:159).
• [124479] High CVE-2011-3099: Use-after-free in PDF with corrupt font encoding name. Credit to Mateusz Jurczyk of Google Security Team and Gynvael Coldwind of Google Security Team.
• [124652] Medium CVE-2011-3100: Out-of-bounds read drawing dash paths. Credit to Google Chrome Security Team (Inferno).

And some additional rewards for issues with a wider scope than Chrome:

• [Linux only] [$500] [118970] Medium CVE-2011-3101: Work around Linux Nvidia driver bug. Credit to Aki Helin of OUSPG.
• [$1500] [125462] High CVE-2011-3102: Off-by-one out-of-bounds write in libxml. Credit to Jüri Aedla.

Many of the above bugs were detected using AddressSanitizer.

We’d also like to thank Aki Helin of OUSPG, Sławomir Błażek, Chamal de Silva, miaubiz, Arthur Gerkis and Christian Holler for working with us during the development cycle and preventing security regressions from ever reaching the stable channel. $9000 of additional rewards were issued for this awesomeness.

Say you’ve found an awesome recipe on your work computer while... ahem... working hard at the office. But when you get back home, you can’t quite remember if it was two teaspoons of baking soda or two teaspoons of baking powder. Wouldn’t it be cool if you could pull up the same recipe on your home computer with one click?

With today’s Stable release of Chrome, you can. When you’re signed in to Chrome, your open tabs are synced across all your devices, so you can quickly access them from the “Other devices” menu on the New Tab page. If you’ve got Chrome for Android Beta, you can open the same recipe tab right on your phone when you run out to the store for more ingredients. The back and forward buttons will even work, so you can pick up browsing right where you left off.

Open tabs aren’t the only things that sync when you sign in to Chrome. Signing in to Chrome also syncs your bookmarks, apps, extensions, history, themes, and other settings. That way, when you sign in to Chrome, you can have your personal Chrome experience on all your devices. Just go to the Chrome menu and select “Sign in to Chrome.”

While Chrome will be updated to the latest Stable version over the next few days, the tab sync feature will be rolled out more gradually over the coming weeks. Thank you for your patience and we hope you enjoy staying in sync!