Chrome 20 On Linux Gives Seccomp Filters For Flash

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.

The Last Day Of Firefox

Well, as I’d promised I used Firefox and only Firefox for a week. This is the last day of use and I do have to say I’ll be going back to Chrome.

I liked Firefox but there’s nothing that really stands out. The best thing is that I can’t close pinned tabs. That’s really the best part of it right now.

But the startup is slow because of the pinned tabs and Firefox as a whole is definitely slower than Chrome in terms of UI responsiveness and page loads. WordPress is a really good example of this, it’s nearly instant on Chrome but Firefox hiccups.

I like NoScript too but there’s no way I would run with Scripts Globally Blocked — huge pain in the ass. Without that there are still protections but not nearly as many. While the Globally Blocked would provide significant security the Globally Allowed does much less – the part that stands out is ClearClick, which is meant to protect against clickjacking.

While I’ll miss NoScript I don’t think that Globally Allowed protects me enough to make it worth it.

NoScript v Sandbox

Where Firefox has NoScript Chrome has a Sandbox. The two aim to do very different features.

NoScript protects against attacks like XSS, clickjacking, and it’ll block websites from loading up Javascript, Plugins, WebGL, which can be used to exploit the machine.

Chrome’s sandbox is meant to protect against attacks that would use RCE to compromise a system. By locking the browser into a strict environment malicious code is not able to interact dangerously with the system.

The difference is that NoScript really protects the browser session itself and Chrome protects the system. So for something like getting online to bank it might be better to go with Firefox with NoScript and HTTPS-Everywhere but if you’re worried about visiting an exploit page that’ll try a drive-by you’ll likely want Chrome.

Thankfully on Linux you can use AppArmor or SELinux or another LSM to restrict Firefox but the Chrome sandbox goes beyond LSM.

So for my personal use I find Chrome to be the more secure option. For specific tasks like online banking I might consider Firefox.

All in all it’s a matter of multiple factors. Performance, security, and stability. I actually had no crashes or glitches with Firefox or Flash in Firefox, which surprised me. I rarely have issues with Chrome either but I do on occasion. In terms of performance though there’s no question and for me personally Chrome is providing the security I want.

So it’s back to Chrome for me.

I’ll see if I can get my friend from Moz to write something, I’m sure he’s dying to get Chrome off of his system.

Another Universal ASLR Bypass Demonstrated

I’ve talked about ASLR issues in the past due to Windows/Linux implementation issues. It’s become more common to see these issues get exploited lately, though still surprisingly few times.

The most recent bypass was with Adobe Reader X and you can read about it here.

Basically some address doesn’t get randomized (VirtualAllocEx maps don’t randomize for some reason) and so they can insert their own ROP code.

There is no way to solve this without Windows picking up slack and randomizing more areas of address space/ specific calls (ie: what PaX does for mmap() base addresses and the hardened toolchain.)

Thankfully this shouldn’t bypass the Reader sandbox and it should be avoidable without Javascript enabled. EMET users are also safe against ASLR bypasses because they’ll benefit from EAF, though EAF is trivially bypassed.

A reminder that implementation flaws in something like ASLR are still around today even though it’s been years since PaX demonstrated the technique.

This vulnerability is pretty interesting and actually makes use of an issue in the sandbox having to do with the IPC handling of syscalls. For more on that you can read the actual post. While the way the sandbox is handled provides an avenue of attack the fault here is most definitely on Windows.

Chrome Site Isolation

Chrome already implements multiple powerful methods to sandbox and limit separate parts of the browser. It seems that they’re working on something new – Site Isolation.

You can enable this already with:


But it’ll break things. For me it broke my extensions like LastPass.

It looks interesting. I’ll read more about this later and post.

Adobe Flash For Firefox Gets A Sandbox

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.

Chrome Sandbox Change On Windows

Up until recently the renderer for Chrome tabs ran at a ‘Low Integrity’ meaning that it could only read/write to low integrity files and folders. Perhaps coincidentally (though I doubt it) after the pwnium exploits broke out of the Chrome sandbox Chrome now runs the renderer at untrusted, meaning it can only access ‘Untrusted Integrity’ files and folders.

By default there actually aren’t any areas of the Windows OS that have Untrusted integrity so this pretty much means the Chrome renderer no longer has disk access capabilities.

Google hasn’t said anything about this, which I find odd, so perhaps it’s a bug in process explorer? Doesn’t seem to be but who knows.

Either way, it’s a significant restriction if they’ve managed to do this.

Why I Sandbox Chrome With AppArmor

Google Chrome is a browser designed with least privilege in mind. The Chrome multiprocess architecture sandboxes each tab, the renderer,  the GPU, and extensions and has them use IPC to talk to the ‘browser’ process, which runs with higher rights. The idea is that all untrusted code (websites) is dealt with on the lowest possible level (the renderer has virtually no rights) and then the renderer deals with the trusted browser process. It’s very effective and there hasn’t been a single Chrome exploit in the wild.

On Linux the Chrome sandbox makes use of a Chroot, seccomp mode 2 filters, SUID, and a few other techniques. On the outside this seems really secure, the problem is that the documentation is outdated and not nearly as clear as the Windows documentation.

To use Chroot you need root, so for the browser process to Chroot the other processes it needs root. Chrome seems to find a way around this using SUID where it runs as root under a separate name, I don’t really know, again the documentation doesn’t cover this at all.

Basically, it sounds really strong but if I don’t understand something I can’t consider it secure.

That’s why I apparmor Chrome. I know how AppArmor works, I know it’s track record, I know what my profile allows and what it doesn’t allow. And I know that even if Chrome is running at root my apparmor profile will limit it.

I would post my AppArmor profile for Chrome up here but it’s fairly specific to my needs. For those of you looking to sandbox Chrome make sure you use a separate profile for the sandbox, chrome itself, and the native client bootstrap.

PPAPI Flash For Linux Finally Seems Ready

PPAPI Flash is the Flash plugin built into Google Chrome that allows for more secure Flash by virtue of the Chrome Sandbox. Adobe has declared that Flash 11.3 will not be supported for Linux except for the PPAPI version so if you’re looking for the latest you’re going to need to use Chrome.

The Flash sandbox isn’t very tight in Chrome as we can see by Vupen’s bypass so a tighter sandbox is very welcome.

Until very recently the plugin was super buggy and unusable. This seems to have changed and I’m noticing no issues.

The PPAPI Plugin is limited to Chrome Beta right now so you can either way ~1 month for it to hit stable or you can download the beta now.

Patching Really Is Necessary

There are certain things in the tech world that go from Myth A to Myth B. The “ghz” myth is one of these things – a CPU’s clockspeed is measured in ghz and people used to use this as the go-to benchmark for determining performance and they’d ignore everything else. Now people go around saying that “ghz” doesn’t matter at all, which is equally stupid.

I see this with patching. Patching used to be the go-to practice for keeping an application secure. A program that was quick to patch was more secure and that was a way to measure security. Now people pretend that patching doesn’t matter – that if you use techniques like ASLR/DEP and you sandbox your applications you don’t need to worry. I see this all over.

This is incorrect. Patching is an invaluable layer in any security setup and I think the latest Chrome exploit shows why.

Google Chrome makes use of ASLR (very strong ASLR), DEP, and SEHOP. It has a fairly finely grained sandbox for each process on Windows. It’s a nice mixture of policy and technology.

And yet it’s still hackable. No matter how much policy you have it will have flaws. No matter how many memory techniques you implement there will be backdoors. Do those methods make things way more secure? Absolutely – there’s never been a single exploit in the wild that bypasses Chrome’s sandbox, even their relatively weak Flash sandbox.

But if you’re looking for security in depth you’d better patch because if you’re running Chrome 14 there’s been a thousand holes since then and it’s simply a matter of chaining the right ones together.

And this applies to everything. In Linux I’m running Chrome, which implements an incredibly secure sandbox, which is highly reinforced by the patches I make to my kernel. But if I’m running a super old unpatched version of Chrome all an attacker has to do is google for some exploits and chain it all together.

The cost of attacking a user is drastically lower when the exploit code is already available and there’s documentation on the vulnerability. By patching you force the attacker to find a new vulnerability, and in the case of a program like Chrome you actually end up forcing them to come up with a dozen vulnerabilities.

There is one simple reason why the entire threat landscape would have to change if Linux were suddenly the most popular OS. It’s not some magic memory technique or sandbox, it’s patching. All of my applications are always up to date on Linux, on Windows they aren’t. And hackers take huge advantage of that.

So do yourself a favor. Keep your system up to date.

Formally Introducing Chromebox – ChromeOS For The Desktop

Chromebox is the new desktop system by Google and Samsung that comes packaged with ChromeOS.

Let’s Talk About ChromeOS First

ChromeOS has been a widely misunderstood Operating System that’s been trivialized as a “toy” OS. I have to disagree – while ChromeOS may feel limiting its goals are admirable: provide a fast and secure device for users to browse the web on. And I must say it truly accomplishes that – even on my CR48 sporting a single core ATOM CPU I manage to do quite a bit with ChromeOS.

Is ChromeOS for the developer who custom compiles his own kernel and needs to boot into Windows to play games and yada yada yada? No, definitely not. ChromeOS is designed and targeted for specific users who simply want to get online. And the fact is that’s most of us. 90% of what I do is done in the browser and a very large chunk of the remaining 10% could easily be moved to the browser if I were motivated to do so.

So ChromeOS is definitely not the OS for everyone but before you dismiss it take a look at some “average user” you know and think about their usage habits. How limiting would ChromeOS really be for them?

Still, it remains to be seen whether or not ChromeOS is truly ready for mainstream adoption. This latest revision was a large overhaul, it’s hard to predict the future.

Chromebox – The Specs

  • Intel® Core™ 2 Celeron B840 processor
  • 16GB Solid State Drive
  • 4 GB RAM
  • Built-in dual-band WiFi 802.11 a/b/g/n
  • Gigabit ethernet
  • 6 USB 2.0 ports
  • 2x DisplayPort++ Output (compatible with HDMI, DVI, VGA)
  • DVI-I single link output (compatible with VGA)
  • Bluetooth 3.0™ compatible
  • Kensington™ key lock compatible

It’s no monster by any means. You won’t be playing Crysis on this thing. But 4GB of RAM, a SSD, and a pretty nice dual core CPU is more than enough for browsing. I mean, seriously, 4GB of RAM is actually a ton considering. And that dual core will handle 720p Flash very well, hell it’ll even play 1080p video. ChromeOS is also one of the few Linux based operating systems that is supported by Netflix and the hardware looks absolutely fine for that.

Chromebox – The Look

The hardware is small. It feels very HTPC to me. Sleek and minimalist – very in keeping with ChromeOS.


The new ChromeOS 19 UI is a far stretch from the previous UI. It’s far more conventional and, of course, that means it’s more comfortable for your home user. The new ChromeOS UI contains a taskbar, launcher, and the ability to detach and move tabs/ windows.


So What Can I Do With This Thing?

ChromeOS has come a long way. It’s got a built in media player, offline Docs editing, offline Gmail, and, of course, access to all of Google’s cloud-based services such as Google Music.

Anything you can do in Chrome you can do in ChromeOS. And that’s a surprising amount.

So What Can’t I Do With This Thing?

The Chromebox comes with a mere 16GB HDD. This isn’t a storage device, you’re not going to keep your thousand photos and videos on it. But, that’s not really the idea. The idea is to keep your data online via Google Drive and the Chromebox simply acts as a conduit to those services. Maybe that’s not your thing.

Is ChromeOS For Me?

Honestly, there is no single operating system for every user. But if you find yourself spending all of your time in the browser and you’re looking for a system that’s going to get you online instantly in a secure manner, yeah, I’d say you should go pick up a Chromebox.

And Then There’s Price

The Chromebox lands at $329.99 from Amazon. A quick search on Amazon for “desktop” between 300-350 shows me computers with similar specs (but includes other hardware) for virtually the same price. This is nice to see, one of the largest complains for the Chromebooks was that the price was too high.

A lot of people feel that they’re getting a “lesser” OS, that it’s less capable and therefor worth less money. I disagree. As of ChromeOS 19 I think it is very easy to call it a fully featured operating system.

The price seems fair but I’m inexperienced as I’ve never purchased a desktop. Perhaps a bit high as it doesn’t come with peripherals.


It only seems right to wrap this up. I think Chromebox is pretty cool and I know a few people that could definitely benefit from a secure system like it.

What Google needs to focus on is getting Docs up to speed so that it’s a real competitor to Word. Getting NativeClient to be more mainstream would be a huge boon to ChromeOS as well. And I, personally, would love to see a proper (free) Cloud IDE that would allow remote storage through Google Drive or Dropbox.

I predict Chromebox will not do too well. It’ll see a quick spurt of people buying it up but, unfortunately, there isn’t enough appreciation for the niche product nor is there the willingness to even try to adapt.