The first Pwnium competition held earlier this year exceeded our expectations. We received two submissions of such complexity and quality that both of them won Pwnie Awards at this year’s Black Hat industry event. Most importantly, we were able to make Chromium significantly stronger based on what we learned.

We’re therefore going to host another Pwnium competition, called... Pwnium 2. It will be held on Oct 10th, 2012 at the Hack In The Box 10 year anniversary conference in Kuala Lumpur, Malaysia.

This time, we’ll be sponsoring up to $2 million worth of rewards at the following reward levels:

• $60,000: “Full Chrome exploit”: Chrome / Win7 local OS user account persistence using only bugs in Chrome itself. 
• $50,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 kernel bug. 
• $40,000: “Non-Chrome exploit”: 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. 
• $Panel decision: “Incomplete exploit”: An exploit that is not reliable, or an incomplete exploit chain. For example, code execution inside the sandbox but no sandbox escape; or a working sandbox escape in isolation. For Pwnium 2, we want to reward people who get “part way” as we could definitely learn from this work. Our rewards panel will judge any such works as generously as we can. 

Exploits should be demonstrated against the latest stable version of Chrome. Chrome and the underlying operating system and drivers will be fully patched and running on an Acer Aspire V5-571-6869 laptop (which we’ll be giving away to the best entry.) Exploits should be served from a password-authenticated and HTTPS Google property, such as App Engine. The bugs used must be novel i.e. not known to us or fixed on trunk. Please document the exploit.

You may have noticed that we’ve compressed the reward levels closer together for Pwnium 2. This is in response to feedback, and reflects that any local account compromise is very serious. We’re happy to make the web safer by any means -- even rewarding vulnerabilities outside of our immediate control.

Another well-received piece of feedback from the first Pwnium was that more notice would have been nice. Accordingly, we’re giving about two months notice. We hope this gives enough time for the security community to craft more beautiful works, which we’d be more than happy to reward and celebrate.

Chrome: Amazon has released an official Send to Kindle extension for Google Chrome that allows you to send any web articles directly to your Kindle device in one click. More »

 

The Dev channel has been updated to 22.0.1229.6 for Windows, Mac, and Linux.  A complete log of what changed can be found in the svn revision log.  Instructions and download links for our different release channels are available on the Chromium wiki.

The Chromium Vulnerability Rewards Program was created to help reward the contributions of security researchers who invest their time and effort in helping us make Chromium more secure. We’ve been very pleased with the response: Google’s various vulnerability reward programs have kept our users protected and netted more than $1 million dollars of total rewards for security researchers. Recently, we’ve seen a significant drop-off in externally reported Chromium security issues. This signals to us that bugs are becoming harder to find, as the efforts of the wider community have made Chromium significantly stronger.

Therefore, we’re making the following changes to the reward structure:

• Adding a bonus of $1,000 or more on top of the base reward for “particularly exploitable” issues. The onus is on the reporter to provide a quick demonstration as part of the repro. For example, for a DOM-based use-after-free, one might use JavaScript to allocate a specific object type in the “freed” slot, resulting in a vtable dereference of 0x41414141. 
• Adding a bonus of $1,000 or more on top of the base reward for bugs in stable areas of the code base—see below for an example. By “stable”, we mean that the defect rate appears to be low and we think it’s harder to find a security bug in the area. 
• Adding a bonus of $1,000 or more on top of the base reward for serious bugs which impact a significantly wider range of products than just Chromium. For example, certain open source parsing libraries—see below for an example. 

The rewards panel has always reserved the right to reward at our discretion. At times, rewards have reached the $10,000 level for particularly significant contributions. An extraordinary contribution could be a sustained level of bug finding, or even one individual impressive report. Examples of individual items that might impress the panel include:

• Nvidia / ATI / Intel GPU driver vulnerabilities. High or critical severity vulnerabilities in the respective Windows drivers, demonstrated and triggered from a web page. Submissions on Chrome OS would also be interesting. Chrome OS typically runs on a device with an Intel GPU. 
• Local privilege escalation exploits in Chrome OS via the Linux kernel. Chrome OS has a stripped-down kernel, so a working exploit against it would certainly be worth examining. We reserve the right to reward more generously if the exploit works inside our “setuid sandbox” and / or our fast-evolving “seccomp BPF sandbox”. 
• Serious vulnerabilities in IJG libjpeg. For well over a decade, there hasn’t been a serious vulnerability against IJG libjpeg. Can one be found? 
• 64-bit exploits. Any working code execution exploit on a 64-bit Chrome release. Sandbox escape not required. 
• Renderer to browser exploit. Any working browser code execution exploit, starting from the assumed precondition of full code execution inside a normal web renderer or PPAPI process. 

Aside from the new bonuses, it’s worth recapping some details of the existing reward structure that aren’t as widely known:

• Our reward program covers vulnerabilities in Adobe Flash as well as other well-known software such as the Linux kernel, various open-source libraries and daemons, X windows, etc. 
• Our base reward is $2,000 for well-reported UXSS bugs, covering both the Chromium browser and also Adobe Flash. (With the new reward bonus for exploitability, UXSS rewards will likely become $4,000.) 
• Our reward program already includes a bonus of $500 to $1,000 when the reporter becomes a more involved Chromium community member and provides a peer-reviewed patch. 
• We have always considered rewards for regressions affecting our Beta or Dev channel releases. It’s a big success to fix security regressions before they ship to the Stable channel. 

To illustrate how the new reward bonuses will work, we’re retroactively applying the bonuses to some older, memorable bugs:

• $1,000 to Atte Kettunen of OUSPG for bug 104529 (new total: $2,000). We believe that our PDF component is one of the more secure (C++) implementations of PDF, hence the $1,000 top-up. 
• $3,000 to Jüri Aedla for bug 107128 (new total: $4,000). There is a $1,000 bonus because this bug affects many projects via core libxml parsing, and we added a $2,000 bonus for exploitability: this is a heap-based buffer overflow involving user-controlled data with a user-controlled length. 

We’re more excited than ever to work with the community and reward their efforts.

The Stable channel has been updated to 21.0.1180.79 for Mac, Linux, Windows and Chrome Frame

This build fixes a security issue with Adobe Flash. You can read more about this in Adobe's Security Bulletin.  

The Stable channel has been updated to 21.0.1180.77 for Mac, Linux, Windows and Chrome Frame

This build fixes a problem with an item in Node::attributes disappearing (Issue 140473).

Chrome: Google Chrome has a built-in speech recognition system, but you can only use it in certain places. Dictation is a webapp that uses Chrome's speech recognition engine, but allows you to dictate much larger chunks of text right inside a simple webapp. More »

• Update Adobe Flash to version 11.3.31.226
• Update GTalk Plug-In to version 3.3.3
• Wifi/3G stability fixes
• Audio fixes

• 29198 - Built-in Ethernet link cycles up & down sometimes  
• 141717 - 3G: Clicking 'Buy Plan' not working if Wifi disabled
• 141737  - Tab hangs when playing a Vimeo playlist in the couch mode

Just over a month ago, at Google I/O, we announced significant changes to Chrome’s packaged application platform. These changes are intended to allow apps to break out of the browser, work offline by default, and enable richer, more immersive experiences.

With the latest version of Chrome in the developer channel, you can build, load, debug and test your apps without command-line flags, although you may need to enable experimental APIs in some cases. Because we’re still in developer preview mode, the Chrome Web Store doesn’t yet accept uploads of these new packaged apps. We’ll enable web store support later this year, and when we flip that switch, users will be able to discover and download your apps directly from the store.

In order to get started building apps, visit our developer documentation at developer.chrome.com/apps and check out our growing list of sample applications on Github (thanks for the pull requests; keep them coming). If you’d like to reach us while you’re building apps, you can join us on the #chromium-apps Freenode IRC channel, join the chromium-apps group or report an issue.

We’re also starting a regular weekly hangout every Tuesday at 9:30am (Pacific Time). Our first one will take place on Tuesday, August 14th. You can add a reminder to your calendar and then tune in at Google Developers Live. And be sure to add +Google Chrome Developers to your circles to keep up on the latest from the Chrome team.

The Dev channel has been updated to 22.0.1229.2 for Windows, Mac, and Linux.  A complete log of what changed can be found in the svn revision log.  Instructions and download links for our different release channels are available on the Chromium wiki.  If you find what you think is a new bug, please file it in our issue tracker.

Known issues:

The Beta channel has been updated to 21.0.1180.77 for Mac, Linux, Windows and Chrome Frame

This build fixes a problem with an item in Node::attributes disappearing (Issue 140473). 

Another month, another market share report and this time it’s for the desktop web browsers. With the upcoming release of IE10, Internet Explorer continues to lose its market share, down from 54.02% to 53.93% (0.09 point decrease). After a streak of market share loses, it looks like Firefox has recovered and has since increased its [...]

The Stable channel has been updated to 21.0.1180.75 for Mac, Linux, Windows and Chrome Frame

This build fixes:

• Flash videos not longer remaining in fullscreen when clicking a secondary monitor while the video is playing  (Issue: 140366). 
• Flash video full screen displays on wrong monitor (Issue: 137523)
• REGRESSION: Rendering difference in Chrome 21 and 22 that affected on Persian Wikipedia (Issue: 139502)
• Some known crashes (Issues: 137498, 138552, 128652, 140140)
• Audio objects are not "switched" immediately (Issue: 140247)
• Print and Print Preview ignore paper size default in printer config (Issue: 135374)
• Candidate windows is shown in wrong place in Retina display (Issue: 139108)
• more of the choppy and distorted audio issues  (Issue: 136624)
• Japanese characters showing in Chinese font (Issue: 140432)
• Video playback issues with flash-based sites (Issue: 139953)
• Sync invalidation notification broken after restart (Issue: 139424)

A little more than two years ago, engineers on the Chrome team began a very ambitious project. In coordination with Adobe, we started porting Flash from the aging NPAPI architecture to our sandboxed PPAPI platform. With last week’s Chrome Stable release, we were finally able to ship PPAPI Flash to all Windows Chrome users, so they can now experience dramatically improved security and stability as well as improved performance down the line.

To appreciate just what a big step forward this is, it helps to understand a bit more about the history and architecture of NPAPI plug-ins. At its core, NPAPI is a thin layer of glue between the web browser and a native application. In the early days of the Web this provided a tremendous advantage, because it allowed third-party plug-ins to evolve rapidly and implement new capabilities, moving the whole web forward.

Unfortunately, as the web evolved, the past benefits of NPAPI became liabilities. The thinness allowed legacy browser and OS behavior to bleed through and crystallize to the point that it hamstrung future improvements. As browsers add compelling features like sandboxing, GPU acceleration, and a multi-process architecture, the legacy of NPAPI severely impedes or outright prevents us from extending those improvements to any pages with plug-in content.

By porting Flash to PPAPI we’ve been able to achieve what was previously impossible with NPAPI for the 99.9% of Chrome users that rely on Flash. Windows Flash is now inside a sandbox that’s as strong as Chrome’s native sandbox, and dramatically more robust than anything else available. And for the first time ever, Windows XP users (specifically, over 100 million Chrome users) have a sandboxed Flash—which is critical given the absence of OS support for security features like ASLR and integrity levels.

Beyond the security benefits, PPAPI has allowed us to move plug-ins forward in numerous other ways. By eliminating the complexity and legacy code associated with NPAPI, we’ve reduced Flash crashes by about 20%. We can also composite Flash content on the GPU, allowing faster rendering and smooth scrolling (with more improvements to come). And because PPAPI doesn’t let the OS bleed through, it’s the only way to use all Flash features on any site in Windows 8 Metro mode.

Moving forward, we’re finishing off the PPAPI Flash port for Mac OS X and hope to ship it soon. And Linux users have already been benefiting from PPAPI Flash since Chrome 20, along with Chrome OS users who have been running it for almost a year. Soon all Chrome users will have access to the improved security, stability, and performance of PPAPI Flash.

One of the great things about the web is that you can hop from page to page watching videos, playing games, or checking email without installing additional software that may pose a security risk to your computer. On the Chrome team, we’ve made it our mission to build a browser that helps protect you every step of the way, defending against pages that try to install malware or steal information without your knowledge. 

Some of the most important things keeping you safe in Chrome are Safe Browsing, auto-updates, and sandboxing. Our goal is to improve each of these features, staying ahead of the bad guys to help keep you safe online. 

With last week’s Chrome Stable update, we took a major step forward in security by bringing an even deeper level of sandbox protection to Adobe Flash Player on Windows. Since 2010, we’ve been working with Adobe to sandbox the Flash Player plug-in to protect users against common malware. Now, thanks to a new plug-in architecture, Flash on Windows is inside a sandbox that’s as strong as Chrome’s native sandbox, and dramatically more robust than anything else available. And for the first time ever, Windows XP users have a sandboxed Flash, making them much safer online. 

Chrome OS has had this deeper Flash sandboxing from the beginning, Linux has had it since Chrome’s last stable release, and Mac support is on the way. Ultimately, this means a safer experience for you as you browse the web. We take the security of Chrome extremely seriously, so we’re excited to be delivering these enhanced protections, and we’ve enjoyed collaborating with Adobe on this effort.

The Dev channel has been updated to 22.0.1229.0 for Windows, Mac, and Linux.  A complete log of what changed can be found in the svn revision log.  Instructions and download links for our different release channels are available on the Chromium wiki.