|
I’m choosing the X200 that I installed coreboot on as my primary workstation and this post will detail why.
I’m switching to the X200 primarily in response to the vulnerabilities that have been discovered in the last year. Specifically, the ability to execute arbitrary code on the Intel ME.
Intel’s Management Engine (ME) is an always-on subsystem that is separate from the main processor and runs proprietary firmware. As long as the computer has power, this separate processor continues executing, even if the user’s operating system is not.
This subsystem has direct access to the Ethernet controller, providing it networking capabilities outside of the user’s operating system’s networking stack. Because it has a DMA engine, it has full access to the system’s memory. Because it lives in the PCH, it probably has access to all attached IO devices.
Importantly, this access is separate from the user’s operating system - this means that the user’s operating system cannot impose restrictions and is not aware that it is sharing the computer’s devices.
Modules can be loaded to provide features - more on this at the Wikipedia link above.
The ME is involved in the bringing up of the main processor - this is achieved by the Bring Up (BUP) module. The machine will not boot without this module.
Each ME module is signed by a special private key that only Intel has, and the ME will only execute signed modules. Each module is obfuscated using confidential huffman tables making reverse engineering difficult but not impossible.
Intel has resisted showing any code for the ME, and resisted offering a processor line that did not require the ME.
Several vulnerabilities have been discovered recently.
Specifically,
Blackhat 2017 saw the “Running Unsigned Code in Intel Management Engine” presentation, which exploits what is fixed by SA-00086. This presentation highlights what is the most frightening scenario:
The PCH carries almost all communication between the processor and external devices; therefore Intel ME has access to almost all data on the computer, and the ability to execute third-party code allows compromising the platform completely
This attack is a proof of concept that requires physical access to an unpatched machine. It is possible to install the firmware update and remove this specific vulnerability, but with physical access an attacker could flash an older firmware that is vulnerable and then exploit that. The only way to notice if this has occurred is to show the firmware’s checksum every time you boot your machine (which itself isn’t reliable: what code performs and shows the firmware checksum?).
There’s no indication that the rate of discovered vulnerabilities are slowing. If anything, the world has woken up to the idea that the Intel ME can be a target. Fortunately no vulnerability has been turned into an exploit that affect large numbers of people without requiring physical access. I’m honestly worried that will happen at some point. The ME is too lucrative a target - because of its unrestricted access, compromising it would provide the skeleton key to your machine, creating an undetectable and unfixable root kit.
Not much. Every Intel processor made in the last 10 years requires the ME to boot.
The me_cleaner project aims to remove as many parts of the
ME as possible from an SPI flash image without affecting core machine
functionality (namely, the bring up of your machine). An external SPI
flasher (like the setup I used to install coreboot on my X200) can read
the ME chip, and one can remove as many modules as possible with
me_cleaner.
Notably, removing modules using me_cleaner does not help in with the
“Running Unsigned Code in Intel Management Engine” exploit, because
me_cleaner leaves the BUP module in, and that is where the
vulnerability lives.
Intel will probably take steps to combat what the me_cleaner project
is doing, so it likely won’t be a good defense in the future.
The X200 is one of the few machines that can work with the Intel ME completely replaced by an open alternative. By installing coreboot and using an open alternative to the ME the entire subsystem can be removed from these machines.
I’d like to emphasize that this is a personal choice in terms of the list of security tradeoffs that can be made. Anyone will tell you that computer security is not a matter of absolutes but a matter of layers and tradeoffs. Even running coreboot without the Intel ME, this X200 isn’t fully free - the EC is still Lenovo’s, as are other blobs in the mainboard.
This machine is still vulnerable to attacks that require physical access (Evil Maid, a hardware keylogger, cold boot RAM read). I would notice if the original Lenovo BIOS was flashed back on, but the X200 remains vulnerable if someone has physical access and flashed a compromised coreboot. I usually rule out attacks requiring that level of physical access (an hour or more with my machine without my knowledge) when making security related decisions. This may sound like a cop-out but I’ll reiterate: security is about tradeoffs.
Asserting more ownership over my hardware by removing the Intel ME is an increase in security that involved tradeoffs I was willing to make. I can’t with a straight face claim that this increased ownership makes me invulnerable to all attacks, nor is it total ownership. There’s a difference between free (as in freedom) hardware and hardware that is executing free software.
It’s important to me to be able to assert ownership over my computing devices. It bothered me that I could probably but not fully trust the hardware I was using. I’m choosing security over performance, screen resolution, and battery life. I view it as similar to choosing DVDs over Blurays - I can completely rip and back up DVDs, but their resolution is lower than Blurays. It’s a tradeoff, a choice between what to value.
I would also like to emphasize that there isn’t yet a publicly known exploit that is driving my choice. The presense of the Intel ME represents a potential vulnerability that I wasn’t comfortable with. Currently, executing non-Intel code on the Intel ME requires physical access. There was another report of accessing the ME through the USB bus but I haven’t heard any follow up, and even that attack requires physical access (plugging in to the machine’s USB port). An exploit that can compromise a machine by accessing the Intel ME without requiring physical access would be almost apocalyptic but no such exploit is publicly known yet.
The potential vulnerability that the presense of the ME represents is similar to the potential vulnerability when using a publicly available wireless Internet - it’s most likely OK but there’s always the chance that someone is ARP poisoning you and MITMing all your traffic, or stealing cookies sent over unencrypted HTTP sessions. Whether or not you want to take steps to secure yourself (for example always tunnelling your traffic through a VPN) is up to you and how you think about risk.
I think it’s a valid assertion, given my stance, that I should be taking more action if I am uncomfortable with the presense of the Intel ME. I have a lot of machines that I use - why haven’t I abandoned those as well, turned them off, or at least disconnected them from the Internet?
First, I have taken an additional step. mica has been removed from duty as the router for my house, and replaced with a TP-Link Archer running OpenWRT. This puts an ARM based machine as the first hop into my home network.
Second, in thinking about the risk for each of these machines, there is elevated risk for a user’s primary workstation compared to file servers that run next to nothing. It’s the user’s primary workstation that receives emails, runs arbitrary programs, and browses the web. Most exploits will target these programs.
Third, if my file servers are compromised the attacker would have access to my backed-up home directory. This includes SSH keys, GPG keys, VPN certificates, and more. To mitigate against this risk, all SSH and GPG keys have a strong passphrase protecting them. Each VPN certificate requires Duo authorization, so the attacker would have to steal or compromise my phone as well.
Now, having access to all my files would still be pretty bad. If I wanted to mitigate that risk, I would have to consider my file servers to be untrustworthy. I would store only encrypted blobs there (eg. with something like Minio) instead of simple files (eg. with rsync). Right now I do trust my file servers, which is to say that I trust FreeBSD and Debian running a minimal amount of services on hardware in my house to be secure.
Let’s say my file servers were compromised. Beyond having access to my backed up home directory, what else would that mean? Let’s also suppose that there is an Intel ME exploit. A keylogger could be installed there that would have access to the passwords used to create the GELI / LUKS mount devices, but if the file server was already compromised then they would have access to my files anyway. A virus from the crypto locker family could encrypt all my files and ask me for payment to decrypt them, but I would either restore from an earlier ZFS snapshot, or just delete everything and re-backup from my workstation.
A malicious attacker could simply write zeros over every sector on every disk, but that would be ok too: there are unique (in the sense that they only exist on my file server, not my workstation) files on my file server - I run several daily jobs to download things like new podcasts. In each of these cases, losing the latest version is ok because these are replaceable: everything I’m not willing to lose is on my workstation and several external encrypted hard drives purposely not always connected to a machine.
Compromising my file server would mean that an attacker has access to my files, but not my workstation. This is important because compromising my workstation would mean access to my SSH and GPG keys. Because it means access to those keys (and their passphrases), it also means that I could lose basically everything: remote access to VPSes, saved passwords (access to every account), emails, money (Internet banking), and so many other things I’m not even aware of because I take the integrity of my main workstation for granted.
So, should I do more? In the scenario where there is an apocalyptic Intel ME exploit requiring no physical access, there are two cases.
The first case is where the exploit would require running a program on
your machine. In this case, the second point from above still stands:
the primary risk will be workstations, not servers. This is not to say
that servers will not be vulnerable, but that I can trust ssh.
The second case is where the Intel ME’s networking stack can be exploited. In this case, my file servers will be vulnerable to attacks only within my network: no routing rule exists that will map an external port to an Intel ME’s networking stack. The primary risk will be my workstation connected to public networks.
So, after all this, should I do more? I don’t think so. If there are further announced exploits, then I will have to rethink this position.
There are also secondary benefits.
The X200 is not vulnerable to Spectre according to the SpectrePoC program. I tried executing with many different cache hit thresholds and could not get the exploit to work.
magnus only has a 256 GB SSD, and I was continually running into that limit. sleevedeck has a 1 TB SSD, which is a lot more room, and this allows me to have my complete home directory (not just a subset) travel with me.
The X200 is easier to repair than the XPS, and parts are a lot less expensive and easier to come by.
And of course, the keyboard.
There are definitely downsides: the screen is 1280x800, CCFL backlit, and not IPS. There are no USB 3 ports. The battery life is roughly 2 hours.
The CPU is slower but not as slow as you’d think.
The GPU only supports OpenGL version 2.X:
$ glxinfo | grep Max
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
This means that any hobby game engine or graphics development cannot use newer OpenGL versions.
|
|
The hostname for this machine is sleevedeck, combining sleeve
and deck from two favourite novels of mine.
I chose that name primarily because it sounds cool, and if I think of computers as sleeves I’m “inhabiting” many sleeves every day. Each sleeve has different capabilities, and more importantly I’m not limited by any one of them. I’m limiting myself if I think that any one machine is limiting me. At best, lack of resources is only friction.
Enough people have asked me why I’m using this old laptop that I thought writing a blog post and linking to it would be beneficial. In explaining why, I have to defend my choices, so my goal in writing this all out was to make sure I wasn’t fooling myself, to weigh the benefits and consequences of my actions and decisions, and to lay out my thinking.