This section presents a thorough insight into Google Chromebook’s key features and details of security and integrity protection architecture of this device.
Now, for the old-school people like I am, that want to kill everyone who comes even close with a finger to the screen, Google makes the Chromebook. The Chromebook actually has a keyboard, so you are not touching on a sensor face that you are trying to read from. Essentially, the architecture of the Chromebook is completely different. You have a Google account that you sign on to, or there’s a guess account. The whole Chromebook is designed to be shared, quite in contrast – and this is why the business background is so important – to the iPad. The iPad is designed to be “one user – one iPad”, so they sell more devices. The Chromebook is actually designed to be shared, so you can log on with as many Google accounts as you want. It’s in standard Linux operating system; it has pretty strong prevention of running third-party code (anything that’s not shipped); it has a personal firewall – once we told them, they actually turned on IPv6 firewalling as well; and it also does automatic silent updates, so you can’t actually prevent the thing from updating, it will always be online and it will always check for updates and update itself.
The only thing you are supposed to run is the Chrome browser, I’m pretty sure everyone is familiar with the Chrome browser. It runs in separate processes, rendering a main process. It has several sandboxing mechanisms that were pioneered by the guys. It hides the full file system from you, so if you click on something that is not displayable in the browser, the dialog where you can save stuff will only tell you – here’s your home directory, and here’s your temp directory; and that’s it, you don’t see the full file system. It’s not a security feature, it’s just meant to prevent you from saving it anywhere else where you can’t. Finally, of course they have Flash in the Chrome browser, they compile it themselves; and of course Adobe Flash completely ignores this, so if you have a Flash app then you see the whole file system, and you can save stuff anywhere.
Anyone remember the MD5 collision CA certificate from 2008 by Alex Sotirov and the guys, where they made an SSL certificate based on the MD5 collision? Most browser vendors went the way of saying: “Because it was signed by Equifax” (and Equifax actually is a valid CA, as valid as CAs go); so they went ahead and took this collision certificate that was obviously evil, and included it explicitly in the browser so they could blacklist it. Google did the same thing, but forgot the blacklisting part. So they explicitly included this certificate, but it’s not blacklisted. So if you manage to convince the Chromebook that today is 2004, you have a valid SSL certificate – if you are Alex Sotirov, because you’ll need the private key on this one.
What they also have in contrast to the Apple products is the ‘developer mode’. So there’s a little switch in the device that you turn on, and then it’s developer mode. You get a big scary screen saying something like: “Warning! You’re about to fuck up the Universe!” and then you actually have root access and you can play with the device.
This is a trusted boot process. So, pretty similar to what Apple does, however Google is a bit smarter in the devices because they have the whole chain of boot stub, of firmware loader, of firmware, of kernel and file system – they have two of those. That is really smart because that means while they’re updating one, they’re running the other. So if something goes wrong, they’ll always have a backup to forward back to. Both actually work this way, so you have read-only memory with the root key, that one verifies the firmware keyblock, that one verifies the firmware preamble, that one verifies the firmware body. This loads the kernel and verifies the kernel and the kernel preamble which is additional metadata information, and then the kernel gets loaded, and the kernel makes sure that the file system is cleared. That’s actually a pretty solid thing.
Also, their file system integrity protection is really smart: if anyone of you builds embedded devices, this is how you do it. So what they do is, instead of signing individual binaries, they sign the entire partition. And by that they actually take hashes of the individual blocks of the partition, and then the hash of the hashes gets signed. So you end up only having one hash as the integrity protection of the entire file system. Every time you read block from the block device which is below the file system, you verify that the hash is correct. If it’s not, then you go “Please connect to the Internet, I need to reset myself completely”. But this is really smart because every time you read block, if you read it before, it’s most likely cached, so you don’t have to verify the whole thing again. This is automatically coming from the caching mechanism of your block device driver, so you don’t have to do anything about it. And you only verify crypto on demand, so if you are building small embedded device and you want to make sure that your firmware is intact, this is how you do it. It’s actually really good.
However, even Google makes mistakes. The partition table for example is not integrity protected, so if someone or something changes your partition table, it’s not going to show up. Also, there is OEM and EFI partition, where the vendor of the Chromebook hardware can actually include code for some update or whatever. This is also not integrity protected, so if you are putting an EFI backdoor on the EFI partition, then you own the Chromebook before you even start it, and nobody is going to notice.Also, I looked at the details of this whole thing and I read the code, which nowadays not many people seem to do in security research. So this is what is actually signed. You see here the partition information is missing, so essentially they have something like a format string, where it would put the ID of the root partition and the ID of the kernel partition in when booting. But this is what they sign. Now, obviously (and you see the root hash here at the end), when they start they actually have to fill in the blanks and have the actual IDs that they are booting with. So I haven’t found a way to exploit this, but I recently read a talk announcement that is going to come out later this year from some French guys, that claimed to actually have found a way to exploit this. Because basically, what’s not cryptographically protected is where it will take the hashes from. So you can redirect the hashing algorithm to a different partition than the partition you are actually running from. So apparently they’ve found a way to do it. I was too dumb, but that’s how it goes. Also, keep in mind what I said initially – that the Chromebook is meant to be shared. Now, for this whole trusted boot to work, this read-only bootloader in the beginning has to be really read-only, right? Well, if you have a couple of minutes with the device and a little bit of soldering iron, then the read-only can be made less read-only very quickly, because the chip is well documented and essentially you have to connect two little pins on the flash chip, and then you can ‘tell’ the software to stop being read-only – and the chip will say: “Yup, okay! I’m no longer read-only”; and you can replace the initial firmware loader which, let’s say, in the universities scenario where everyone is sharing Chromebooks, can be quite successful and fruitful. The Chrome OS, in contrast to the Apple devices, actually needs to encrypt the user data; and, again, Google is cram full of very smart people, so they actually developed the pretty decent encryption design for the user content. So even if you have root access to the device, there’s very little way for you to actually get to the user content, unless of course you get his Google ID password – then you’re in, obviously. I won’t bore you with the details. This is how they do the user home encryption. What’s important about this is actually that it’s bound on your user password and the machine, so the key is actually depending on both things. So stealing one doesn’t really help you. The update story with the Chromebook – it checks every 45 minutes; they developed their own protocol, it’s called ‘Omaha’. Updates are incremental, so what they do is, because of the block device signatures that I explained, the update protocol will actually send you new blocks for the block device. So they diff the old hard drive image, so to speak, with a new hard drive image, and send you the difference. What’s really interesting is they also check the integrity when they download the update. What’s interesting about it is they check it after they applied it. So the short of it is they download individual blocks that they write to your hard drive, and then once they are done they check whether the checksum was good. So if anything goes wrong in between…Well, that’s an interesting way to do it; but it’s also wrapped in SSL, so it’s hard to get in there. There are a couple of theoretical attacks that you can do if you have an SSL certificate.