Pwnium2 Is Over – One Exploit And It’s Already Patched

Pwnium2 is Google’s second competition where they challenge hackers to tear into the Chrome browser. The payouts are much larger than the typical bounty program with the highest being 60,000 dollars for an ‘all Chrome’ exploit.

Last year we saw three exploits – one by Sergey Glazunov, one by ‘Pinkie Pie’, and one by the Vupen team. The Vupen exploit was in the NPAPI flash, Sergey Glazunov used UXSS among other things, and Pinkie Pie used a series of escalation bugs to hop from one sandbox to the next.

This year we saw only one exploit and it was by Pinkie Pie. Details aren’t out yet but it was discovered about 8-10 hours ago (by my count) and it earned him 60,000 dollars.

It’s described as:

Critical CVE-2011-2358: SVG use-after-free and IPC arbitrary file write. Credit to Pinkie Pie.

We’re happy to confirm that we received a valid exploit from returning pwner, Pinkie Pie. This pwn relies on a WebKit Scalable Vector Graphics (SVG) compromise to exploit the renderer process and a second bug in the IPC layer to escape the Chrome sandbox. Since this exploit depends entirely on bugs within Chrome to achieve code execution, it qualifies for our highest award level as a “full Chrome exploit,” a $60,000 prize and free Chromebook.

The big deal there being the IPC arbitrary file write – I suspect the SVG use-after-free was just the initial exploit.

The patch has already been issued to the stable channel. I’ll post more after I listen to the talk about the exploit.

Malware In The Chrome Web Store

Google Chrome’s web store is the only place that users can (by default) get Apps and Extensions. Google stated that it’s confident in its ability to remove malware from the store and that by limiting users to it they’re helping to keep them safe.

As I predicted months ago the web store is being targeted by attackers. Naturally when a user sees an app or extension in the store they trust it more than they would one on some random website. Attackers take advantage of this to implant malicious extensions and apps into the browser.

A recent post by barracudanetworks provides information on a recent trend of apps claiming to be free versions of the ‘Angry Birds’ games. The apps request dangerous rights such as being able to access all data on all websites and their origin is very suspicious.

These apps have been downloaded nearly 100,000 times. The apps inject advertisements into webpages as a way to make money.

Barracudanetworks notes that this isn’t the first time it’s happened and they’ve seen other extensions do something similar.

Months ago I predicted this exact situation. Google needs to seriously step it up. They need to put out a new set of permissions (they’re currently working on a new set of refined permissions) and start vetting extensions that make use of dangerous ones.

NSS Labs Study Finds Internet Explorer Most Secure Against Click Fraud

An NSS Labs study conducted over 175 days has found that Internet Explorer is the most secure browser when it comes to protecting against Click Fraud.

Key findings from the NSS Labs report include:

  • Click fraud itself causes minimal direct harm to the typical end user as the ultimate target is the ad buyer.
  • Consumer and corporate users, however, are infected by additional malware as a by-product of click fraud installation.
  • Click fraud catch rates are Chrome 1.6%, Firefox 0.8%, Internet Explorer 96.6%, and Safari 0.7%.
  • Services are available that may help ad buyers identify click fraud.  However, service contracts with ad networks may contain clauses that restrict ad buyers’ ability to recover damages for click fraud.
  • The average lifespan of a click fraud URL was 32 hours with over 50% expiring within 54 hours.

The results show Internet Explorer ahead by an incredibly sizable portion – leaving Chrome in second place at a measly 1.6%, Firefox at .8%, and Safar at .7%.

Click Fraud is a type of attack that really hits advertisers, not so much the users. That’s why it’s so surprising that Chrome, a product driven by Google, is receiving such a poor score.

I’m also not about to call NSS labs out but they sure do seem to have a lot of reports indicating Internet Explorer is the most secure browser or rather they only seem to release reports about things that IE excels at (and often by massive margins). It would be really nice to have another independent research group test things out. When Accuvant did a study comparing browsers (NOT that this study was unbias) they found basically no difference between IE and Chrome in terms of detecting malware, which was contrary to a study by NSS labs that showed IE outperforming Chrome by about 60%.

Take it with a grain of salt but it’s worth noting.

Google Chrome Stable Channel Hits 22

The Google Chrome browser has been updated to version 22. There’s nothing too exciting about it but there are a multitude of vulnerabilities that have been patched. Google notably payed out for a Critical vulnerability described as “Windows kernel memory corruption”, which warranted a full 5,000 dollar reward.

Another High vulnerability was labeled “UXSS in frame handling” (UXSS stands for Universal Cross Site Scripting). This was submitted by Sergey Glazunov who used another UXSS exploit to break out of Chrome’s sandbox in the pwnium awards.

There are 24 vulnerabilities in total though a few of them consist of many bugs.

Given how quickly Chrome users are updated to the latest version it is unlikely that there will be any exploits in the wild for these vulnerabilities despite their severity. That said, get your Chrome updated so you can be sure.

Move Chrome’s Cache To RAM (Guide For Linux Users)

Browsers will keep ‘pieces’ of a webpage in what’s called a cache. This cache allows them to quickly pull files from the disk (which is quite somewhat quick) instead of having to redownload them (which is slow). Your system’s RAM is even faster than your disk, hundreds of times so, and keeping a file in RAM means accessing it will be nearly instant. Browsers are going to load up these files to RAM regardless but we can speed up writes to the cache and improve privacy by having the entire cache kept in RAM from the beginning. To do so we’ll be creating a RAM disk and then telling Chrome to use it.

Remember, your cache is deleted every time you shut down your computer if you follow this guide. It will get rebuilt the next session.

First off we’re going to create a directory in /tmp/ , which we’ll call ccache.

mkdir /tmp/ccache

Then we need to open up /etc/rc.local. The commands in /etc/rc.local are run whenever the system starts up. Enter the following line, which tells the system to mount the RAM disk at /tmp/ccache/. You’ll see size=700M. Keep in mind that this is in Bytes and it’s how much RAM you’re allocating to the new filesystem. You can change that size to whatever you want but I don’t think anyone’s going to be using much more than 300MB, but I keep some extra room in there.

mount -t tmpfs -o size=700M,mode=0744 tmpfs /tmp/ccache/

We now set the permissions on /tmp/ccache (recursively) to 777. For some reason 777 is all that’ll work for me.

chmod 777 /tmp/ccache/ -R

Now that’s all set up we need to create a Chrome desktop shortcut. However your distro lets you do that, just drag it wherever. Right click it, properties, and add the following (word press messes up double -‘s. You’ll have to type those out).

–disk-cache-dir=”/tmp/ccache/” –disk-cache-size=600000000

Now when you launch Chrome from that shortcut it’ll use the disk cache we’ve set up.

Now, in terms of privacy what we’ve done is eliminated the ability for an attacker with access to your system to view your cache/ try to see what you’ve been up to *except* for that session. Every time you shut your system down you lose the cache, as such no one can see where you’ve been.

If you were on some dodgy site or doing something sensitive or whatever all you have to do is restart the system and there will be no trace left (in the cache at least).

It may or may not be worth the trouble to you. Since Chrome’s already mapping this stuff to RAM anyways you shouldn’t expect any major performance improvements. But those who fear micro-writes to their SSD can use this to prevent wear/tear.

Pwnium Two – Google Chrome To Hold Another Hacking Contest

Google had so much fun with the Pwnium competition the first time they’ve decided to hold another one. This should be interesting as we’ll get to see if Chrome exploits are really worth 60,000 dollars or if attackers are more willing to sell to higher bidders.

The rewards are similar though now instead of a 1 million dollar limit there’s a 2 million dollar limit. This is largely irrelevant as it is very unlikely there will be that many exploits.

The competition essentially lets a bunch of people come together and see how far they can break Chrome. Last competition we had three exploits bypass Chrome’s sandbox – One by Pinkie Pie, one by Vupen, and one by Sergey Glazunov.

The Vupen exploit was pretty lame and used the Flash plugin. The Flash plugin for Chrome is now PPAPI and far stronger than it used to be so Vupen’s going to have to find another way to get out of the sandbox.

The Vupen exploit was not revealed but the others were. They made use of 6 and 12 bugs respectively and were really brilliant.

Chrome’s sandbox has improved since the last competition – the renderer now runs at Untrusted as does Flash – so it will be fun to see how people break out this time.

Chrome Beefs Up Its Rewards Program – Bigger Bounty

Google has announced that it’s upping the rewards handed out for its Chromium Bounty Program. The bounty program has apparently begun to stagnate – Google attributes this to vulnerabilities being more difficult to find due to their security efforts – and they hope to increase the input of reported vulnerabilities by increasing the payout.

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.

Good news for Chrome users – finding bugs doesn’t just mean that you no longer have to worry about that particular one, it also leads to improvements in how other vulnerabilities are found and how the browser can mitigate entire classes of vulnerabilities in the future.

Chrome Seccomp-BPF Sandbox

Chrome://sandbox has gotten an update reflecting the newly implemented Mode 2 Seccomp Filters implemented through the Berkley Packet Filter (BPF). To learn more about Syscall and Seccomp Filtering you can read this post and learn about how Chrome’s new sandbox on Linux.

Chrome’s seccomp sandbox is a powerful restriction on how Chrome can interact with the system’s kernel. This limitation is an effective way to prevent kernel exploitation, which is a wonderful reinforcement to Chrome’s SUID sandbox. The seccomp sandbox is ideal for a program like chrome, programs that already implement some form of sandboxing. The best way to escape from a sandbox, outside of a sandbox design issue, is to exploit the kernel – doing so allows you to bypass almost any security implemented, and the seccomp sandbox attempts to mitigate this threat.

Check to make sure that you’re adequately sandboxed by going to chrome://sandbox.


Comparing PPAPI Flash To Firefox Flash Sandbox

Chrome 21 hit Windows a few days ago and I’ve been meaning to write a post letting users know that they should know be running the PPAPI Flash Plugin by default (check chrome://plugins), which enables a far more restrictive sandbox.

How much stronger is this sandbox? IBM has written a wonderful whitepaper about it comparing the Firefox NPAPI Flash Sandbox, Chrome NPAPI Flash Sandbox, and the newly rolled out Chrome PPAPI Flash Sandbox.

The PPAPI Sandbox adds a number of restrictions. Here’s a few screenshots of the presentation that highlight some important areas.









As you can see the Pepper Flash is significantly more secure than the NPAPI Plugin used previously and currently. It has considerably reduced read access, write access, and registry access as well as stronger and more restrictive job tokens.

The first sandbox bypass for Chrome by Vupen used the Flash plugin because the sandbox for it was the weak link. Firefox’s sandbox has improved somewhat over the old Chrome sandbox but the latest iteration, Pepper, is much stronger than either of the two.

Flash exploits in the wild are going to drop significantly, just as they did with Adobe reader.

Some Really Interesting Chrome Statistics

The following chart shows the usage of plugins over a 28 day period for Chrome users who opted into data usage monitoring. Really interesting. 99.9% of users used Flash at least once. A full 58% used the PDF reader. And only 12% used Java.

Plug-in name Percentage
Flash Player 99.9%
Chrome PDF Viewer 58%
Silverlight 26%
Java 12%
QuickTime 4%
Windows Media Player 2%