In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can't be removed, this means avoiding all recent generations of Intel hardware.
http://libreboot.org/faq/#intel
Original comment follows:
Former Thinkpad fan. I love my new Dell Rugged Extreme. I got the 12. This thing is built the way Thinkpads used to be (complete with the price tag of a used car).
The only thing(s) I don't like about it is the missing trackpoint. I really miss that. And the fact that black-box UEFI is built in (but what do we know about modern microcode anyway, might as well get some ostensible security measures for 'free'). Oh, one more: the "QD" connectors do not accept standard straps/slings -- only insanely expensive (and hard to find) Dell brand straps/handles.
Everything else about it is outstanding. This thing is a brick with rounded, rubber edges.
Drive over it with your truck. (watch the video)
Use it as body armor. (no, don't really)
Go scuba diving in the arctic. (Check out the frozen-in-an-ice-block video on Youtube.. while running on battery.)
The screen is incredibly bright, but it also has a slick quick-kill for all the lights. Just the thing for when a warlord is on your tail. The multi-color LED backlit keyboard looks awesome.
It runs Kali Linux (built on Debian Jessie) perfectly. Everything works, including the touch screen and stylus, out of the box.
UEFI isn't any more black-box than BIOS in general. Sure, I'd rather run entirely FOSS firmware, but in the absence of that, UEFI doesn't make things any worse. If anything, it allows quite a bit more introspection and extensibility. And its core is FOSS (https://github.com/tianocore/edk2), just not the versions shipped by board/system vendors.
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_In...
Note that this level of enterprise control has been possible for some time; even without IME, if HR hands you a laptop and doesn't tell you the BIOS password, then it might be set to, say, attempt to network PXE boot by default from the corporate intranet's deployment-and-compliance servers.
---
[1] Actually it's more literally like the kind of "smart" server-rack backplane that allows you to connect a remote serial console to an unresponsive server to see what's going on, or send it a hard reboot or whatever else. Except for managing desktops instead of servers.
It's hard to argue with metaphors, because they start out being inexact and go downhill from there. (oh, another one!) But I'll try anyway :)
It's really nothing like group policy's or configuration profiles, except it could be used to deliver similar functionality for your machine from either the manufacturer, or from your company, or from anyone else along the way who implemented their own backdoor into your hardware during shipping[1] or maybe just inserted their own microcode into the CPU, because it literally is an all-powerful hardware backdoor that lives below your OS. It can even be upgraded remotely in many cases.
Backdoors can be used for good or for evil, of course, but that's what it is. (and it actually has nothing to do with hypervisors, unless you take the metaphor that any operating system you install is really running under the control and whim of the Intel Management Engine.) Again, the metaphor of a remote management console is again over-simplifying, but, sure, it can do that, too.
When you're reading this[2], remember that you don't control those keys and you can't remove that software. You can't 'just turn it off':
1. http://gizmodo.com/the-nsa-actually-intercepted-packages-to-... 2. http://libreboot.org/faq/#intelme
What I meant was that, the same way the userland runs at the control and whim of the kernel, and the kernel at the control and whim of the hypervisor, the hypervisor itself will run at the control and whim of IME. Because IME sits at ring -2 (yes, that's a thing now), the hypervisor at ring -1, the kernel at ring 0, and userland at ring 3. So it's actually more than "hypervisor-level access", but a hypervisor is almost as capable, so it's a decent comparison.
> ...except it could be used to deliver similar functionality...
That's what I was trying to communicate, yes. The purpose (not the functionality) of IME is to enable enterprise management. Like Group Policy or Configuration Profiles, like server backplane management, like running your app as a VM on a hypervisor, like a lot of things.
The point is that these technologies exist to enable companies to control and manage their hardware assets. None of them are built in such a way that they can reach out and bite you if they haven't been set up and configured by the computer's owner, any more than someone could interface with your computer's serial console without attaching a serial cable to it.
A lot of devices come with privileged backdoors, for a variety of reasons. For example, a lot of CPUs have a JTAG debugger chip embedded, exposed via GPIOs. But since such backdoors require hardware access to enable, they're not all that scary. Of course your device isn't secure if someone gains physical access to it. While they were in there, they might have also installed a Bluetooth-transmitting in-line keylogger chip or something.
Now, what might be scary about IME is that it's enabled by default. But a lot of things are also insecure by default until hardening is applied, and have to be secured in a clean-room environment: Windows, for example. If you care, you do this.
But I don't see its existence in particular as troubling, insofar as it doesn't represent any greater loss of control than was already true. Intel chips (and I'm pretty sure those of most other CISC manufacturers) have been running microcode updated via encrypted blobs for decades; this microcode can have any number of backdoors embedded in it. You don't need a fancy special-purpose coprocessor to do this stuff; the main processor is perfectly capable of doing Intel's bidding instead of yours without any help. The IME just allows your computer to do the bidding of some arbitrary third-party that Intel likes (like DRM companies), instead of the code needing to be written by Intel themselves, embedded deep in the CPU's internals.
Note also that most firmware chips can be re-flashed to do bad things; CPUs are not alone in presenting this "bugged out-of-the-box" attack-vector.
...but then, to go one step further: if you don't trust Intel's chips because of their firmware, why does it matter whether it's firmware or not? Backdoors can be embedded in the traces of the CPU itself. Having updatable microcode doesn't change this; the existence of the IME doesn't change this. Do you think the NSA can't requisition a one-off custom variant printing of a CPU, and get that stuck the board of a Person of Interest's laptop, or phone, or TV, instead?
This is why I was concentrating on the Intel AMT (remote Internet access) feature of the IME: it's the only part that materially changes things from how-the-world-was before its existence. If you're an end-user and own your computer, you can disable AMT, and verify that it's disabled—the computer will no longer reply to probes on that port. Everything else is just a dozen new vectors for motivated attackers to do things motivated attackers have always been able to do.
As you move downward into more primitive levels of the system, or outward to edge parts of the system (ie a usb attachment), it becomes harder to see what's going on. For example: let's say that you p0wned the firmware on a non-boot SATA drive. You could see all the bits flying across, but you can't do much about them except tamper with them; they might be encrypted, or you maybe can't get access to the network in order to ship them off elsewhere. There's probably ways around each of those, but it's hard. But what if I took a Raspberry Pi and stuck it on the system bus? that's a different story :)
When you have a multi-megabyte secondary server and processor that's hooked directly into your system bus, watching everything that comes across and able to subtly react, tamper, watch just for keys, or ship data off elsewhere, then (as you point out) the attack vectors multiply compared to a exploiting a device's firmware. And, you can't ever get rid of them. EVER. No amount of flashing will fix it, because you can't flash it anyway. (That's why I posted the libreboot IntelME link).
What if just the hardware RNG (rdrand) watched for a particular sequence of bits to come into some registers, and then started spitting out a predictable sequence for random numbers?
What if this wasn't even a crazy conspiracy theory? (It's not, as we know now, although we don't know the exact mechanism that hardware RNG's are owned by). :(
> The IME just allows your computer to do the bidding of some arbitrary third-party that Intel likes (like DRM companies), instead of the code needing to be written by Intel themselves, embedded deep in the CPU's internals.
Yes, agreed - that's a radically different level of surface area.
Any firmware can be reflashed, but this isn't just any firmware; this is firmware that connects everything together. This is literally the heart of the system. And it's completely locked off from our even viewing it, let alone choosing not to using it.
> If you're an end-user and own your computer, you can disable AMT, and verify that it's disabled—the computer will no longer reply to probes on that port
Agreed, but you originally said you can disable IME, and that's all I was really taking issue with :)
Disabling AMT still leaves IME: what is it doing? You don't know, and we'll never tell you ;)
> Everything else is just a dozen new vectors for motivated attackers to do things motivated attackers have always been able to do.
Agreed. :(
Thank you for the interesting discussion! It'd be fun to relax and argue about it sometime in person. :)
Dells business range isn't so bad. I bought a Latitude in January of last year and, although it had some superfluous fluff bundled with it, it was lean enough that I didn't bother to format and reinstall from scratch (although I dual boot). I previously bought a Lenovo ThinkPad for more and returned it because the depressing build quality (I don't remember much about the bundled software because it simple doesn't factor in to my purchasing decisions).
I think the fact that this spyware was found on a refurbed ThinkPad shows just how far the brand has fallen.
The machine in this article is a Thinkpad.
Not that I'd ever buy a device with Windows preinstalled anyway, nor do I recommend it.
Otherwise business class systems are typically better about pre-installed cruft.
You can say many things about Apple, but at least when you buy their hardware you know exactly what to expect. If you used one of their laptops you've used them all.
But, to your point -- Apple hardware, like most modern laptops, are built on Intel chipsets and cryptographically signed to prevent tampering by the owner. You're locked out of your own laptop.
If you're concerned about security or even if you just like to hack on the stuff you paid for, it's probably not where you want to be. You have no idea what's going on in there, and it's heavily encrypted at multiple layers to keep you from finding out. See my comment above: you were backdoored before the operating system was even installed. I was too, with my sweet new matte black Dell. (See my comment above).
The sad part is that there are very few modern laptops (if any) that we're not steadily being locked out of. It's not just Apple. It's (almost) everyone. and, of course, it's our phones, too. Check out the libreboot and coreboot websites for some modern(ish) gear that isn't backdoored.
That Rev. Stallman uses their laptop speaks for Lemote's trustfulness.
Maybe buying direct from another manufacturer on the list in the link I posted or buying a laptop or PC without an OS on it solves 95% of the problem. Maybe I'm just assuming too much here.
I guess this confirms my initial point when it comes to hardware, people are not that well informed.
via