Why I Preordered An Acer C720 Chromebook

A lot of people aren’t super into Chrome OS, but I personally think it’s a great operating system for netbooks. They’re light as hell on your resources and Chrome OS is arguably the most secure consumer operating system around.

So, why did I buy the Chromebook?

The Hardware


The Chromebook has somedecent specs for the price (270 dollars after everything),

  • CPU: Haswell Celeron 2995U. 1.4GHz, dual-core, 2MB Cache
  • RAM: 4GB DDR3 (Soldered down…sorry kids. 4GB RAM should be enough for anybody)
  • Display: 11.6″ 1366×768 (16:9)
  • Disk: 16GB SSD (NGFF connector)

Now, this is not the most powerful device in the world. Intel really screwed up in my opinion when they left AVX and AES-IN instructions out of this CPU, but it’s still not weak at all. 4GB of RAM is definitely adequate for browsing and using many apps. A decent screen, and a SSD.

The hardware is really quite decent for a netbook, certainly for the price (comparable ACER notebooks are the same price). There’s also a really great battery life – 8.5 hours, and in my experience Chromebooks typically get as good or better battery life than advertised.

This is perfect for travel or going to my classes, which is 99% of the workload it’ll get.

The Software

Chrome OS is a really cool operating system. In my opinion, it’s the ideal operating system for a netbook. Whereas other operating systems will boot up taking 1GB of RAM, or more, just for the OS itself, ChromeOS (last I checked) boots with under 100MB usage. It’s a very stripped down and optimized Linux system, booting in just a few seconds. The hardware is completely dedicated to the operating system, so even though the specs aren’t very powerful, they’re not going to waste time on anything.

Chrome OS is easily the most secure operating system in terms of protecting the user from infection or exploitation. The Chrome sandbox on Linux is something I’ve written about in the past and I feel very confident in its security. As I’ve recently written about, Native Client apps, which allow for very low level and powerful programs to run on your Chromebook, are also placed into a sandbox.

On the topic of Native Client, I think it could be huge for Chromebooks. Right now many apps are glorified bookmarks – you click them, they take you to a site, and that’s it. Once Portable Native Client is released in Chrome 31 developers will have the tools to port projects that already exist over to ChromeOS with ease. LastPass has already started work on a Native Client binary plugin, and other projects can potentially be ported.

I’ll also be able to use my Chromebook to control other computers I own that run Chrome via the Chrome Remote Desktop plugin. That means that, should anything arise that my Chromebook can’t handle, I can simply control a system that I own that can handle the task.

The majority of the Chromebook usage is going to be Netflix, Google Docs, and Cloud 9 IDE, but I think I’ll have a lot of fun with it. I may at some point turn on Dev mode and start hacking at the low level stuff, but for the most part I just want a low maintenance system that I can take around with me.


Native Client Sandbox – Sandboxing Sandboxing

For those of you don’t know, Google’s Native Client is a way for browsers to run native code within the browser. In other words, I can write a C/C++ program (or any other LLVM supported program) and run it within the browser – pretty cool! The benefits are all over the place but, basically, ChromeOS has been largely criticized for being a ‘limited’ operating system, with apps that aren’t very powerful, and NaCl provides a way for developers to create secure and powerful applications.

But NaCl isn’t the first project to try to do this. The infamous Active X tried beforehand and, as we all know, totally sucked in terms of security. Will NaCli be a massive hole in an otherwise secure browser? Nope. Because Google poured on the security goodness here once more. Seriously, I realize most people don’t have the monetary capabilities of Google, but they do a hell of a lot when it comes to securing products these days.

We all know by now (if you don’t, read more of my posts!) that Chrome runs in a pretty cool sandbox. On Windows sandboxing is limited and, while Chrome does an excellent job, Linux provides more tools for sandboxing that address critical issues. On Linux, even conservatively, the sandbox is very impressive. Your renderer process, the most exposed codebase, is running with no rights – it can’t interact with the kernel, it has no file access, it basically gets fonts and that’s it. It’s locked into a tight sandbox. Yet Google decided that, for NaCl, they’re going to add *yet another sandbox*, which means that all NaCl code runs within the Chrome sandbox and the NaCl sandbox. In short, the Native Client process is a PPAPI process that runs in the Chrome Renderer process, so it is limited in the same ways.

That’s pretty cool. What’s cooler is how the NaCl sandbox works (without getting into PPAPI and the proxy it’s kind of not doing it all justice, but I’m writing this spontaneously at 3am oh well!).

On x86 NaCl uses a processor specific feature called segmentation. Segmentation, something I’ve seen used in PaX, the group who invented security techniques such as ASLR, is a method for the CPU to change which areas of address space are accessible to programs, and their rights. Unfortunately, segmentation is not supported on other architectures, and NaCl supports ARM and 64bit as well as x86. Just like PaX found a work around, so did Google – the implementation differs between ARM and x86_64 but the goals are all the same. (Upon watching a video on NaCl he also skims over it – anyone know more on the documentation? Seems like for 64bit they just use guard pages to separate the data/ code ‘segments’.)

NaCl executables are built with a toolchain that does a couple of pretty interesting things. NaCl executables are compiled without specific instructions, they’re blacklisted and will simply not be allowed into the codebase. Interestingly, they ban ret… so instead of returning, you jmp, push, pop. There’s a toolchain feature that has to do with alignment of instructions, rather than get into the details, the point is that you can’t jump into the middle of a chain of instructions, you have to jump to the beginning. When the toolchain returns your assembly it’s provided a safer and saner memory model that invalidates the ability to exploit specific types of vulnerabilities.

NaCl also performs instruction validation. If it sees any blacklisted instructions it kills the process, naturally. It basically does a check, before runtime, on the file to ensure that it’s not trying to perform actions that shouldn’t be allowed (though if you use the toolchain these should never be built in anyways).

Again, all of the visible attack surface from a NaCl executable is also sandboxed. That means that even if I get out of the NaCl sandbox through the proxy interface or through the renderer I’m still stuck in what are essentially the strongest sandboxes currently implemented on consumer systems and I still need to leverage another attack to get out.

I’d love to take each specific area of the sandbox (like the ret removal) and just break down exactly how that works and how effective it is, but this was a post of boredom and inability to sleep. The sandbox itself is very complex, but pretty cool. I’m not quite sure how I feel about it right now, but, as an extra layer I think it’s somewhat ideal in its goals at least. We’ll see how it works out, I’m looking forward to the next Pwnium when we’ve got NaCl built in. I’d also love to see Google add a 20,000 dollar bug bounty reward for NaCl sandbox bypasses like they’ve done for broker sandbox bypasses..

I probably missed a lot of stuff, most of what I’ve read was a while ago, but I’m hoping that we get more documentation soon.

Honestly, I just wish every company had the resources to do what Google does with security. NaCl was some experimental little project hack they made, and they are able to pour massive resources into fuzzing and all sorts of stuff. Really cool.

There are a few great resources on the NaCl sandbox. I’ve read as much as I can about it, but this video is pretty great: https://www.youtube.com/watch?v=5bcyuKh3__0


64bit Chromium Is Building, Chrome To Follow?

Chromium 64bit for Windows appears to be building on Google’s official builtbot. Many users of 64bit Windows will be very happy about this, I’m sure. 64bit leads to potential performance improvements, as well as many security improvements (especially on Windows 8) so this could go very well for everyone.

It will be fun to see what developments come out of Chrome 64bit, and what kind of performance improvements we really see. The potential for performance improvements on a 64bit browser are… mixed, and complicated. Complicated data structures like the DOM won’t enjoy larger pointers and long int values, but there are other performance improvements that will potentially outweigh that.

In terms of security, among other things, Chrome will now be able to use High Entropy ASLR, a feature of Windows 8 that makes ASLR more resilient to specific types of attacks.

Naturally, Linux users have had 64bit Chrome for ages.

PDF.js For Chrome – It Works!

edit: Now available on the Chrome Web Store: (use this! not the one I link later from Opera)


So Opera recently came out with a PDF.js extension for their latest Blink build of the browser. I kinda thought, hey, Opera and Chrome aren’t all that different anymore… maybe it’ll work? So I downloaded the file from:


And I got a pdf-viewer-0.8.169-1.nex and I changed the file extension to pdf-viewer-0.8.169-1.crx. 

I then launched Chrome with the command flag –easy-off-store-extension-install and opened up chrome://extensions. I dragged the .crx file onto the page, and voila – it installed!

So then I opened up the first PDF I found on Google and…

PDFjschromeSuccess! PDF.js now works in Chrome, with just a little bit of work. The extension almost certainly won’t autoupdate, though perhaps it will. No idea. But there you have it.

One of the benefits of PDF.js is that your entire PDF “program” is implemented in Javascript. Chrome runs Javascript in an incredibly tight sandbox in its renderer, so attacks using PDFs will be restricted to that sandbox.

So there you have it. Chrome now has PDF.js, and it’s available on Firefox and Opera as well. For more on PDF.js in Chrome, see my earlier post.


Explaining Chrome’s Linux Sandbox

Note: The documentation for Chrome’s Linux sandbox is lacking. This is my attempt to make sense of it and clarify how it works for users who may not want to sift through multiple docs on the subject. If I have misinterpreted, let me know, some of the docs are out of date and I may not have been informed.

Chrome is well known for its sandbox, which has held up incredibly well over the years – not a single in the wild attack against it. But on the Linux side of things it’s even more impressive, Chrome’s sandbox is immensely more powerful than on Windows. Though the architecture is similar, the mechanism is fairly different.

Chrome’s architecture is made up of multiple parts – on Linux there is a broker, your SetUID Sandbox process, and your tabs, renderer, plugins, and extensions (the Zygote processes).

The Chrome-Sandbox SUID Helper Binary launches when Chrome does, and sets up the sandbox environment. The sandbox environment is meant to be restrictive to the file system and other processes, attempting to isolate various Chrome parts (such as the renderer) from the system.

A sandboxed process is put inside a Chroot, a sort of a virtual file system (chroot = change root, it’s a new root). It basically gets its own file system to work with, an din this case, it’s not given any write access to the system. The limitations imposed on the process prevent it from escaping the chroot.

The sandboxed process is also provided a PID namespace (a way for a process to look like it’s standalone on the machine,  or among a subset of processes), denying it the ability to use ptrace() or kill() other processes. ptrace() in particular is dangerous as it allows processes to read or manipulate data in other processes. Sandboxed processes are unable to ptrace() each other as well (set to undumpable).

A network namespace is used as well in order to prevent sandboxed processes from connecting out – not much documentation on this.

The Broker process, which remains unrestricted by SUID, is what handles decisions about downloading files, writing to the disk, etc. It handles the dangerous stuff, and is unrestricted, but it is separated from the areas of the program that are most open to attack. Using an Apparmor profile will allow restriction even of the broker process. Otherwise it remains confined purely by DAC.

The next layer of restriction is provided by the Seccomp-BPF sandbox. Seccomp filters are something I’ve written about before. Their goal isn’t to protect the system from damage, like the SUID sandbox does, but to protect the system from further exploitation.

Seccomp-BPF works by restricting the system calls that programs can make. The implications of this are covered in this post. A quick summary is that a sandbox, or any form of access control, is only as powerful as the kernel. It is very often the case that, rather than trying to find issues with the sandbox itself, an attacker can simply go after the big buggy kernel running underneath it. An attack on the kernel allows for a full bypass of the sandbox.*

Seccomp works by restricting access to the kernel by filtering the ‘calls’ that can be made to it. The fewer calls a program can make the fewer ways it can exploit the system. Suddenly the kernel isn’t this massive glob of attack surface, it’s a much smaller are, with monitored interaction between it and the program.

Chrome on Windows had its sandbox broken at Pwn2Own by MWRLabs. It was, in fact, a local kernel vulnerable that allowed them to bypass the sandbox once they’d gained access to the renderer. Such an attack would be far more difficult on a Linux system with Seccomp enabled.

Overall the sandbox works by reducing the potential for damage and reducing the potential for local exploitation. Chrome is, as always, pouring work into their security. Their sandbox is very impressive, and I would love to see some research into breaking it.

There was a ‘partial reward’ for PinkiePie exploiting ChromeOS, but it was unreliable. No details have been released yet, quite unfortunately.

*Plug for Grsecurity here. See my guide for setting up a hardened Grsec kernel. Seccomp limits kernel attack surface, Grsecurity makes the entire kernel more difficult to exploit.

Chrome Gets Hacked – Pwn2Own 2013

So Pwnium 2013, held at Cansec West, started today. And while details of the attacks aren’t out, one in particular stuck out to me. This post can be considered something of a “Part 2” to my “Securing Insecure Systems” because it highlights the absolute number one most important thing – a secure kernel is necessary for a secure system.

MWRLabs was the only contested booked for Chrome hacking, and they were successful, leveraging initial RCE/ASLR bypasses on Windows 7 to gain access to Chrome. From there they exploited a kernel vulnerability, and that’s where the fun is.

We also used a kernel vulnerability in the underlying operating system in order to gain elevated privileges and to execute arbitrary commands outside of the sandbox with system privileges.

What people need to realize is that no matter how tight Chrome’s sandbox (Untrusted has no read/write access to the  entire file system, and that’s where they started) there’s an entire complex full-of-vulns kernel sitting right there, ripe for exploitation. And MWRLabs took advantage of that – they broke through the sandbox.

And what does that prove? It proves that no matter what the hell you do to restrict things like file access, if you leave your kernel exposed, you are vulnerable.

On Linux I see, time and time again, that people feel they don’t need PaX/Grsecurity. These people state “Oh, well we have SELinux”. This proves that MAC is not enough. You’re trying to solve an insecure kernel by putting a piece of code in your kernel that restricts file access… nope.

Thankfully, on Linux, there are ways to limit kernel attack surface. You’ve got seccomp mode 2 filters, which filter access to the kernel. By limiting kernel attack surface you make the kernel more difficult to exploit – though this does not negate the need for a patched and hardened kernel.

So what do you want to take from this?

1) No. You aren’t secure if you don’t patch.

2) No. You aren’t secure just because you use SELinux.

Chrome Stable Shipping With Vulnerable Flash Player

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 64bit For Windows Gets A Bit More Progress

Users have wanted a 64bit Chrome browser for quite some time and with Firefox, Opera, and Internet Explorer allhaving 64bit versions (though Firefox does not officially support their 64bit builds) it’s a bit surprising that Chrome hasn’t released one.

The Chromium bug for 64bit support has gotten some activity recently though. We can hope this continues.

The benefits of a 64bit browser are numerous but also variable – 64bit is not magic, you don’t get it to compile for 64bit and suddenly have a super speedy browser, you have to optimize for 64bit and really make sure you take full advantage of the potential that comes along with it.

Some of that potential is directly related to security.

When most people think of 64bit they think of being able to access more RAM. The reason 64bit can access more RAM is because it can address 2^64 bits of data, whereas 32bit can only access 2^32 bits of data. This also means that it can access files of a size up to 2^64bits and that it has an address space of up to 2^64bits (although it’s not that large).

A larger address space will significantly improve ASLR, which relies on randomizing areas of address space. If you want to find random values between 1 and 10, there are only so many times you have to guess no matter how strong the random dumber generator is – make that between 1 and 1,000,000 and things get much harder to guess.

On Windows 8 64bit processes can opt into High Entropy ASLR, which improves the randomization of address space further, by increasing the randomness of memory allocations.

So 64bit Chrome will make things more difficult for attackers, especially on Windows 8.

In terms of performance there may or may not be significant improvements. 64bit comes with a downside, pointers are twice the size, and apparently for a browser that could end up being an issue due to how data is structured. Mozilla was working on 64bit Firefox but dropped the project because the benefits were not outweighing the development costs.

Star the Chromium bug if you’d like to see work on 64bit Chrome and Chromium for Windows continue.

Chrome Gets New “Script Bubble” Feature

Chrome now includes a “Script Bubble” feature that shows you how many scripts are running on a specific page and which ones. The feature could potentially allow users to spot a malicious extension more easily.

There’s no way to stop the extension from running on the page through the Script Bubble, which is something I’d really like to see. Further, I’d like to see scripts on on pages on a whitelist as well and options similar to the other content settings.

You can enable the feature under chrome://flags.