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.

Web browsers are big, complicated pieces of software that are extremely difficult to secure. In the case of Chrome, it’s an even more interesting challenge as we contend with a codebase that evolves at a blisteringly fast pace. All of this means that we need to move very quickly to keep up, and one of the ways we do so is with a scaled out fuzzing infrastructure.

Chrome’s fuzzing infrastructure (affectionately named "ClusterFuzz") is built on top of a cluster of several hundred virtual machines running approximately six-thousand simultaneous Chrome instances. ClusterFuzz automatically grabs the most current Chrome LKGR (Last Known Good Revision), and hammers away at it to the tune of around fifty-million test cases a day. That capacity has roughly quadrupled since the system’s inception, and we plan to quadruple it again over the next few weeks.

With that kind of volume, we’d be overloaded if we just automated the test case generation and crash detection. That’s why we’ve automated the entire fuzzing pipeline, including the following processes:

• Managing test cases and infrastructure - To run at maximum capacity we need to generate a constant stream of test cases, distribute them across thousands of Chrome instances running on hundreds of virtual machines, and track the results.
• Analyzing crashes - The only crashes we care about for security purposes are the exploitable ones. So we use Address Sanitizer to instrument our Chrome binaries and provide detailed reports on potentially exploitable crashes.
• Minimizing test cases - Fuzzer test cases are often very large files—usually as much as several hundred kilobytes each. So we take the generated test cases and distill them down to the few, essential pieces that actually trigger the crash.
• Identifying regressions - The first step in getting a crash fixed is figuring out where it is and who should fix it. So this phase tracks the crash down to the range of changes that introduced it.
• Verifying fixes - In order to verify when a crash is actually fixed, which we run the open crash cases against each new LKGR build.

In addition to manageability, this level of scale and automation provides a very important additional benefit. By aggressively tracking the Chrome LKGR builds, ClusterFuzz is evolving into a real-time security regression detection capability. To appreciate just what that means, consider that ClusterFuzz has detected 95 unique vulnerabilities since we brought it fully online at the end of last year. In that time, 44 of those vulnerabilities were identified and fixed before they ever had a chance to make it out to a stable release. As we further refine our process and increase our scale, we expect potential security regressions in stable releases to become increasingly less common.

Just like Chrome itself, our fuzzing work is constantly evolving and pushing the state of the art in both scale and techniques. In keeping with Chrome’s security principles, we’re helping to make the web safer by upstreaming the security fixes into projects we rely upon, like WebKit and FFmpeg. As we expand and improve ClusterFuzz, users of those upstream projects will continue to benefit.

 I may be old-fashioned in this regard but I prefer websites and companies to know as little about me as possible, unless the information are used for a service that I make active use of. I do not mind Amazon knowing that I’m an adult male, as this is blocking recommendations and offers aimed at a female audience on the site.

From left to right Jim Hebert, Cris Necker, Justin Schuh

Just 24 hours after reporting the critical vulnerability in Google’s Chrome web browser, the search giant has already released a patch to address the issue.

Identified as a bug CVE-2011-3046, discovered vulnerability is described as “UXSS and bad history navigation”, with no additional details revealed.

Having said that, the latest stable build of Google Chrome (17.0.963.78) also fixes earlier reported issues with the Flash games and videos.

Security contests prove to be useful.

Just as some might have thought that Google’s Chrome sandboxing feature is bullet proof, Sergey Glazunov, a security researcher who have found quite a few vulnerabilities in the fast, has enriched his life with a $60k reward, received for a “Full Chrome” exploit, which bypassed the sandbox feature. Although Google Chrome was previously known to withstand various attacks in Pwn2Own and similar contests, this time it was the first to fail.

Justin Schuh, Chrome’s security team member said, “It was an impressive exploit. It required a deep understanding of how Chrome works. This is not a trivial thing to do. It’s a very difficult and that’s why we’re paying $60,000.”

The second exploit was executed by a team from VuPen Security, which took about 6 weeks to write and test. According to Chaouki Bekrar, the co-founder of VuPen Security, they wanted to demonstrate that Chrome not as unbreakable as some might have though.

While details about exploits were not revealed, he said, “We had to use two vulnerabilities. The first one was to bypass DEP and ASLR on Windows and a second one to break out of the Chrome sandbox. It was a use-after-free vulnerability in the default installation of Chrome [which] worked against the default installation so it really doesn’t matter if it’s third-party code anyway.”

The keyword here is “up to”.

As if the Pwn2Own contest was not enough, Google will be holding its own competition at the CanSecWest security conference.

Called Pwnium, contest attendees will be asked to exploit the Google Chrome web browser and in return, will be rewarded as follows:

$60,000 – “Full Chrome exploit”
$40,000 – “Partial Chrome exploit”
$20,000 – “Consolation reward, Flash / Windows / other”

So where does this $1 million reward come from? Well, Google will be giving away money not for the first two or three hackers, but for pretty much everyone, who manages to compromise their web browsers security.

As simple as that.

Security is one of our core values, alongside speed, stability and simplicity. From day one, we’ve designed Chrome’s extension system with security in mind. Since we launched the extension system, the state of the art in web security has advanced with technologies like Content-Security-Policy (CSP). Extension developers have been able to opt into these features, and now we’re enabling these security features by default.

Unfortunately, securing extensions with CSP by default is incompatible with the legacy extension system. We’re passionate about extension compatibility, so we’re going to make this change gradually to minimize pain for users and developers.

Users can continue to install extensions that are available in the store regardless of whether they are secured with CSP or not. This means they will not lose any of the functionality they've added to Chrome.

Developers will be able to choose when to enable the new behavior. To ease the transition, we've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default:

script-src 'self'; object-src 'self' 

This policy imposes the following restrictions on extensions:

1. Extensions can no longer use inline scripts, such as 
   
   . Instead, extensions must use out-of-line scripts loaded from within their package, such as 
   . 
2. Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead. 
3. Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts. 

A recent study from researchers at UC Berkeley suggested that these restrictions, taken together, would substantially improve the security of the extension system:

These defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found. 

For most extensions, updating them to manifest_version 2 will require the developer to move inline scripts out-of-line and to move scripts loaded from the network into the extension package. Developers are not required to update their extensions to manifest_version 2 immediately, but, over time, more of the extension ecosystem will encourage developers to update their extensions. For example, at some point, we’ll likely start requiring new extensions uploaded to the web store to use manifest_version 2. You can find a complete list of changes and more details about CSP in the extension documentation.

With all the privacy and tracking talks going on, it looks like Google will finally be joining the ranks of other web browsers who support Do Not Track feature.

Introduced years ago, Do Not Track allows users to opt out of tracking by advertising, social and other web sites that enjoy such data.

However, it’s not coming anytime soon, according to the report, Google Chrome is likely to introduce Do Not Track feature by the end of this year, which is 8-10 months away.

Susan Wojcicki, Google’s senior vice president said, “This agreement will not solve all the privacy issues users face on the Web today. However, it represents a meaningful step forward in privacy controls for users. We look forward to making this happen.”

Chrome/Firefox: HTTPS Everywhere is a simple extension that, with just a one-click installation, can seriously increase your security on over 1,400 web sites by encrypting your connection. More »

This year at the CanSecWest security conference, we will once again sponsor rewards for Google Chrome exploits. This complements and extends our Chromium Security Rewards program by recognizing that developing a fully functional exploit is significantly more work than finding and reporting a potential security bug.

The aim of our sponsorship is simple: we have a big learning opportunity when we receive full end-to-end exploits. Not only can we fix the bugs, but by studying the vulnerability and exploit techniques we can enhance our mitigations, automated testing, and sandboxing. This enables us to better protect our users.

While we’re proud of Chrome’s leading track record in past competitions, the fact is that not receiving exploits means that it’s harder to learn and improve. To maximize our chances of receiving exploits this year, we’ve upped the ante. We will directly sponsor up to $1 million worth of rewards in the following categories:

$60,000 - “Full Chrome exploit”: Chrome / Win7 local OS user account persistence using only bugs in Chrome itself.

$40,000 - “Partial Chrome exploit”: Chrome / Win7 local OS user account persistence using at least one bug in Chrome itself, plus other bugs. For example, a WebKit bug combined with a Windows sandbox bug.

$20,000 - “Consolation reward, Flash / Windows / other”: Chrome / Win7 local OS user account persistence that does not use bugs in Chrome. For example, bugs in one or more of Flash, Windows or a driver. These exploits are not specific to Chrome and will be a threat to users of any web browser. Although not specifically Chrome’s issue, we’ve decided to offer consolation prizes because these findings still help us toward our mission of making the entire web safer.

All winners will also receive a Chromebook.

We will issue multiple rewards per category, up to the $1 million limit, on a first-come-first served basis. There is no splitting of winnings or “winner takes all.” We require each set of exploit bugs to be reliable, fully functional end to end, disjoint, of critical impact, present in the latest versions and genuinely “0-day,” i.e. not known to us or previously shared with third parties. Contestant’s exploits must be submitted to and judged by Google before being submitted anywhere else.

Originally, our plan was to sponsor as part of this year’s Pwn2Own competition. Unfortunately, we decided to withdraw our sponsorship when we discovered that contestants are permitted to enter Pwn2Own without having to reveal full exploits (or even all of the bugs used!) to vendors. Full exploits have been handed over in previous years, but it’s an explicit non-requirement in this year’s contest, and that’s worrisome. We will therefore be running this alternative Chrome-specific reward program. It is designed to be attractive -- not least because it stays aligned with user safety by requiring the full exploit to be submitted to us. We guarantee to send non-Chrome bugs to the appropriate vendor immediately.

Drop by our table at CanSecWest to participate and check the latest news.

It's no secret that there's big money to be made in violating your privacy. Companies will pay big bucks to learn more about you, and service providers on the web are eager to get their hands on as much information about you as possible. More »

It’s hard for us to believe, but it’s been just over two years since we first announced the Chromium Security Rewards Program.

We’ve been delighted with the program’s success; we’ve issued well over $300,000 of rewards across hundreds of qualifying bugs, all of which we promptly fixed. It also helped inspire a wave of similar efforts from companies across the web, including Google’s own vulnerability reward program for web properties, which has also been

We’ve been fascinated by the variety and ingenuity of bugs submitted by dozens of researchers. We’ve received bugs in roughly every component, ranging from system software (Windows kernel / Mac OS X graphics libraries / GNU libc) to Chromium / WebKit code and to popular open source libraries (libxml, ffmpeg). Chromium is a more stable and robust browser thanks to the efforts of the wider security community.

Today we’re expanding the scope of the Chromium program to formally include more items that deserve recognition:

• High-severity Chromium OS security bugs are now in scope. Chromium OS includes much more than just the Chromium browser, so we’re rewarding security bugs across the whole system, as long as they are high severity and present when “developer mode” is switched off. Examples of issues that may generate a reward could include (but are not limited to): 
  • Renderer sandbox escapes via Linux kernel bugs. 
  • Memory corruptions or cross-origin issues inside the Pepper Flash plug-in. 
  • Serious cross-origin or memory corruption issues in default-installed apps, extensions or plug-ins. 
  • Violations of the verified boot path. 
  • Web- or network-reachable vulnerabilities in system libraries, daemons or drivers.

Chromium OS security bugs should be reported in the Chromium OS bug tracker, whilst security bugs affecting the desktop Chromium browser should be reported in the Chromium bug tracker.

• We may elect to issue “bonuses” ranging from $500 to $1000 if a bug reporter takes on fixing the bug they have found themselves. For eligibility, this process involves working with the Chromium community to produce a peer reviewed patch. These bonuses are granted on top of the base reward, which typically runs between $500 and $3133.70. 

• The base reward for a well-reported and significant cross-origin bug (for example a so-called UXSS or “Universal XSS”) is now $2000. 

Perhaps most importantly, this program reflects several of our core security principles: engaging the community, building defense in depth, and particularly making the web safer for everyone.

Related to this third core principle, we’re particularly excited by all the work that has been done on shared components. For example, a more robust WebKit not only helps users of two major desktop browsers, but also a variety of tablet and mobile browsers.

While the web is a virtual treasure trove of great content, it’s also used by bad guys to steal personal information. One of Chrome’s most advanced security features, Safe Browsing, helps protect against the three most common threats on the web: phishing, drive-by malware, and harmful downloads. We recently announced some new enhancements to Safe Browsing, so we thought we’d offer an inside look into how it works.

Safe Browsing downloads a continuously-updated list of known phishing and malware websites, generated by an automated analysis of our entire web index. Each page you visit, and each resource (such as pictures and scripts) on the page, are checked against these lists. This is done in a way that does not reveal the websites you visit, and is described in more detail in our video on Safe Browsing. If Chrome detects that you’ve visited a page on the list, it warns you with a large red page that helps you get back to safety.

Of course, this only helps for dangerous content that Google already knows about. To provide better protection, Safe Browsing has two additional mechanisms that can detect phishing attacks and harmful downloads the system has never encountered before.

Phishing attacks are often only active for a few short hours, so it’s especially important to detect new attacks as they happen. Chrome now analyzes properties of each page you visit to determine the likelihood of it being a phishing page. This is done locally on your computer, and doesn’t share the websites you visit with Google. Only if the page looks sufficiently suspicious will Chrome send the URL of that page back to Google for further analysis, and show a warning as appropriate.

Malicious downloads are especially tricky to detect since they’re often posted on rapidly changing URLs and are even “re-packed” to fool anti-virus programs. Chrome helps counter this behavior by checking executable downloads against a list of known good files and publishers. If a file isn’t from a known source, Chrome sends the URL and IP of the host and other meta data, such as the file’s hash and binary size, to Google. The file is automatically classified using machine learning analysis and the reputation and trustworthiness of files previously seen from the same publisher and website. Google then sends the results back to Chrome, which warns you if you’re at risk.

It’s important to note that any time Safe Browsing sends data back to Google, such as information about a suspected phishing page or malicious file, the information is only used to flag malicious activity and is never used anywhere else at Google. After two weeks, any associated information, such as your IP address, is stripped, and only the URL itself is retained. If you’d rather not send any information to Safe Browsing, you can also turn these features off.

This multi-pronged protection combines to make you much safer against the most prevalent attacks on the web while carefully guarding your privacy. We’ve always believed in making the web a safer place for everyone, so we also make the Safe Browsing API available for free to other browsers and websites.

Safe surfing!

When we first set out to design Chrome, we knew we had a unique opportunity to improve the security of the web. In addition to speed and simplicity, we’ve been adamant that security be a central tenet of everything we build. Chrome and the web have since come a long way, and we’ve been challenged to protect a complex and rapidly changing browser against the many threats that emerge on the web.

After spending tens-of-thousands of hours working on ways to make users safer on the web, we thought it might be worth sharing the Chrome security principles that guide the work that we do.

There are lots of technical details, but the fundamentals have always been simple. Security should compliment your browsing experience, not detract from it, and your browser should be secure by default -- no configuration required. No defense is ever perfect, so we rely on multiple layers of protection to help guard against single points of weakness. We support and fund the security research community in their work to identify weaknesses, and when vulnerabilities are found, we pride ourselves on patching them faster than any other browser.

These principles have served us well in protecting users while keeping Chrome super fast and easy to use. If you develop software, we hope you find them helpful in securing your own product, and if you’re a Chrome user, that they give some insight into the many ways we work to help you surf with confidence.

Today’s Beta release improves on two of Chrome’s core principles: speed and security.

One of the things people like best about Chrome is that it loads web pages quickly. To get you where you want to go even faster, Chrome will now start loading some web pages in the background, even before you’ve finished typing the URL in the omnibox. If the URL auto-completes to a site you’re very likely to visit, Chrome will begin to prerender the page. Prerendering reduces the time between when you hit Enter and when you see your fully-loaded web page--in some cases, the web page appears instantly.

On the security front, improvements to Chrome’s Safe Browsing technology should help protect you from additional types of malware attacks. Previously, Chrome focused primarily on protecting you from sites that would exploit your computer with no user interaction required. Now, we’re seeing an increase in malicious websites that try to convince you to download and run a file that will harm your computer. Some websites even pretend this malicious file is a free anti-virus product.

To help protect you against malicious downloads, Chrome now includes expanded functionality to analyze executable files (such as “.exe” and “.msi” files) that you download. If a file you download is known to be bad, or is hosted on a website that hosts a relatively high percentage of malicious downloads, Chrome will warn you that the file appears to be malicious and that you should discard it. We’re starting small with this initial Beta release, but we’ll be ramping up coverage for more and more malicious files in the coming months. Remember, no technical mechanism can ever protect you completely from malicious downloads. You should always be careful about which files you download and consider the reputation of their source.

Try out these changes in the new Chrome Beta--we look forward to hearing your feedback. As always, please keep in mind that the Beta channel inherently comes with more bugs and kinks to work out.

A new Google-funded study of browser security by security research firm Accuvant Labs crowned Chrome the champion of security features, and ranked Firefox below Internet Explorer in terms of protection available from web-borne threats. Predictably, Microsoft and Mozilla have different opinions on what makes a browser secure, and why Accuvant's findings are off base. All of this got us thinking about which browser is the most secure, and whether the security features listed in studies like this even matter to the rest of us. More »

Google funded study confirms.

Accuvant, the US based research, firm has published a new study, which compared security features of the three most popular web browsers: Internet Explorer, Google Chrome and Firefox.

As it turns out, the search giant funded study has made a conclusion that Google Chrome is the most secure browser out there, followed by Internet Explorer and Firefox.

After such claims, Mozilla has decided to respond with the following statement:

“Firefox includes a broad array of technologies to eliminate or reduce security threats, from platform level features like address space randomization to internal systems like our layout frame poisoning system. Sandboxing is a useful addition to that toolbox that we are investigating, but no technology is a silver bullet. We invest in security throughout the development process with internal and external code reviews, constant testing and analysis of running code, and rapid response to security issues when they emerge. We’re proud of our reputation on security, and it remains a central priority for Firefox.”

So here you have it folks. Despite continuous IE bashing in various communities, it still managed to beat Firefox in a non-biased study.

What do you think?

Chrome users began reporting the specious detection of the browser early Friday in a quickly growing thread on a Google support forum.

Numerous users complained in Google Forums about the warnings they received in Microsoft Security Essentials, a free, consumer grade anti virus software from Microsoft. According to various reports, WSE identified a problem with Google Chrome web browser and has tagged it as: PWS:Win32/Zbot.

Fortunately, Microsoft became aware of the problem and issued the following statement:

An incorrect detection for PWS:Win32/Zbot was identified and as a result, Google Chrome was inadvertently blocked and in some cases removed from customers PCs. We have already fixed the issue…but approximately 3,000 customers were impacted.

Microsoft told users to update Security Essentials with the new definition file, then reinstall Chrome.

For its part, Google slapped a red warning banner at the top of its Google support pages that read, “Alert: Google Chrome has been incorrectly marked as malware by Microsoft security software.”

Wow, that’s certainly one way to win the browser war. - Andrew Storms, director of security operations at nCircle Security

 

Chrome/Firefox: FB Secure is a Chrome extension that gives you precise control over the permissions that a Facebook application or game gets when you connect it with your Facebook account. For example, if you're connecting an app but don't want it to post to your wall, you can deny those permissions while accepting the rest. More »