Chromium Blog

Announcing Pwnium 2

Wednesday, August 15, 2012

first Pwnium competitionexceeded our expectationsPwnie AwardsHack In The Box

$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.

beautifulworks
Posted by Chris Evans, Software Engineer

Chromium Vulnerability Rewards Program: larger rewards!

Tuesday, August 14, 2012

Chromium Vulnerability Rewards Program

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.

particularly significant contributions

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.

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.

$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.

reward their effortsPosted by Chris Evans, Software Engineer

The evolution of Chrome packaged apps

Thursday, August 9, 2012

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.

Posted by Mike Tsao, Evolved Software Engineer

we announced Check out our overview video for a quick intro to the new platform. developer channelChrome Web Storedeveloper.chrome.com/appssample applicationschromium-appsreport an issuereminder to your calendarGoogle Developers Live+Google Chrome Developers
Posted by Mike Tsao, Evolved Software Engineer

The road to safer, more stable, and flashier Flash

Wednesday, August 8, 2012

last week’s Chrome Stable releaseNPAPI plug-ins99.9% of Chrome users that rely on FlashASLRintegrity levelsPosted by Justin Schuh, Software Engineer and Boring Security Guy

Ending mixed scripting vulnerabilities

Friday, August 3, 2012

end mixed scripting vulnerabilities

We continue to protect end users by blocking mixed scripting conditions by default, but we now do it in a way that is less intrusive. This change minimizes “security dialog fatigue” and reduces the likelihood that users will expose themselves to risk by clicking through the warning.

We’ve improved resistance to so-called “clickjacking” attacks. Electing to run any mixed script is now a two-click process.

We now silently block mixed scripting conditions for websites that opt in to the HSTS security standard. This is the strongest default protection available.

google.comtwitter.comfacebook.comopting in sites to mixed script blocking

Core Security PrinciplesPosted by Chris Evans and Tom Sepez, Software Engineers

NPAPI plug-ins in Windows 8 Metro mode

Friday, July 20, 2012

Chrome in Windows 8 Metro modeNPAPIlike ActiveXAdobe Flash PlayerPDF viewer

Plug-in name

Percentage

Flash Player

99.9%

Chrome PDF Viewer

58%

Silverlight

26%

Java

12%

QuickTime

4%

Windows Media Player

2%

usage statisticsPosted by Carlos Pizano, Software Engineer and Metro Gnome

Introducing getUserMedia and the Javascript Gamepad API

Monday, July 9, 2012

Chrome Beta releasegetUserMedia APIWebRTCrotate the video and add hipstery filtersplay a xylophone with motion detectiontry on glasses with face detectionstep into a photoboothFollow WebRTC on Google+AirMechTommy Widenflycht, Software Engineer and Real-Time Communicator