Google Chrome 23 was just released to the stable channel with some notable security fixes. It’s also shipping out with a vulnerable Flash Player. Chrome bundles its PPAPI Flash Player into updates, which usually means users are patched more quickly or even before official patches are out. The PPAPI Flash plugin also runs in a very restrictive sandbox, on Windows it runs at an Untrusted Integrity Level with job tokens applied to it, and on Linux it runs with the BPF Sandbox among other things.
While this typically means users are ahead of patches, in this case Google fell behind. Users shouldn’t worry too much, even if they did land on an exploit page for the vulnerability (and I don’t believe any are currently in the wild) the sandbox is very strong and they’d be protected from infection.
Google will be releasing the latest patched version shortly.
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.
I was reading the scarybeast blog and he mentions that Chrome 20 now implements the seccomp filters for its Flash plugin.
That means that Flash is now running in a chroot (separate file system) and namespace and it has a whitelist of syscalls.
This is a significant improvements. The thing about sandboxing is that you can only restrict processes with lower rights ie: hardware can constrain the kernel, kernel -> admin, admin -> user, etc. So if I’m being held by an admin account and I get a kernel exploit and get escalation I’ve just made breaking out of that sandbox a whole lot simpler. Chroot happens to have multiple weaknesses when trying to hold a root user (you can compile with grsecurity to remove these) so keeping Flash from elevating privileges will help keep it in its own little chroot’d environment.
Seccomp filters directly reduces kernel attack surface, which prevents kernel exploitation. This is a really nice step forward.
Adobe Flash has long been a source for exploitation on the Windows OS so it’s nice to see it get locked down further on Linux.
Seccomp support is in the 3.5 kernel and Ubuntu 12.04.
Adobe Flash 11.3 for Firefox now runs in a sandbox! Yay. It’s not super strong, it should be virtually identical in nature to Chrome’s NPAPI sandbox, which Vupen broke out of twice. Still, this moves the cost of Flash exploitation far above what it used to be.
Chrome users will also be pleased to know that the PPAPI plugin has moved to 11.3 and it is really stable. I’m running it full time and youtube and google music run flawlessly.
So it’s a good day for security. You can expect Flash exploits in the wild to wither away because all three major browsers now sandbox it. Where will hackers go? Well… either we’ll start seeing more sophisticated attacks on the Windows system (kernel exploits, yada yada) or we’ll start seeing attacks on other plugins like… Java.
My advice… either EMET Java or uninstall it. It’s just gonna get worse for that plugin.