What are the implications of such hardware on user security? Is the threat real, overblown, or relatively unexplored?
There are efforts to reverse engineer it, and a lot of information is known about it.
The problem is:
- Intel has created its CPU to require ME for CPU initialization. So no ME, no CPU. You can neuter most of it but not the part that starts the CPU.
- Intel has locked the space down with strong cryptography and is the only one that can create, read, put or modify code there.
- There's no guarantee that Intel won't use or be forced to use this for a given purpose (good or bad) in the future.
But, any ME backdoor can't really be used remotely without traversing a network. This means:
- The ME might enable someone with physical access to the computer to have free reign through some undocumented or lesser known interfaces (like USB JTAG), but it's far more likely the OS has an exploitable vulnerability in that situation that's at least equivalent (e.g. Thunderbolt DMA). Generally, you are always screwed if your adversary has physical access to the system.
- Theoretically you could monitor the outgoing network traffic from the system and notice anything unusual. This is difficult with most general-purpose operating systems in the way most users use them. But minimal installs of OSes (think Debian netinst) with every process accounted for and every expected network communication also accounted for could potentially be monitored enough from an external system to notice any shenanigans.
- I don't think the ME knows how to talk to anything but the onboard Intel NICs, so you can just install a Broadcom or Realtek NIC (or a USB NIC), don't use the onboard NIC, and probably reduce any remote attack surface here significantly. This is assuming you don't install local OS drivers that allow the OS to interact with the ME over its OS-exposed interfaces and potentially get the OS to do the ME's bidding.
Threat persistence, i.e. persistent rootkits, persistent remote monitoring if one has privs to tickle the CPU instructions that give access. It is just a matter of time before there are public tools for script kiddies to manage the OS within the CPU. Here [1] is an example of someone slowly making progress decoding all the undocumented instructions and here is a talk with a brief overview of the tools. [2] This is not specific to Intel's ME but it is the way people will eventually tame/exploit that beast in my opinion. There are more recent talks that get deeper into security rings in the CPU. This video [3] more related to your question but not specific to ME however can be used to access ME and much more. If this appears to difficult and time consuming just know that some folks out there have the documentation for the undocumented instructions.
You may find some tools on github and other public repos for disabling ME. Use with care. Test on an identical model of system that is at the same firmware/BIOS and same model of CPU as those tools can brick your CPU. As @rocket_surgeron stated, one can buy CPU's with ME disabled but that will not disable the "God Mode" referenced in [3].
[1] - https://github.com/xoreaxeaxeax
As they exist today I expect you've got to be an interesting target for it to matter.
I worry more about ten or fifteen years from now when everyone has the keys
I'm currently using a Raspberry Pi for my NextCloud because it's not Intel (IME), but I'm changing to a Radxa because it's more transparent.
I (will) use a PinePhone with Biktorjg's (more) open firmware as my daily driver because the completely opaque hardware on my GrapheneOS Pixel and LineageOS OP 7T are OBVIOUSLY full of access points for state (or clever) actors.
Not having anything to hide doesn't mean that I don't want privacy. Intel IME and the like are incompatible with that utopia.
Please, feel free to comment on my choice of home server, the Rock 5B isn't shipping yet, there's time to change my mind.
We're stuck with just that blob, but the modem is cut off from the main CPU and DMA by being connected over USB.
Dell, System76, and Librem all sell at least some systems with ME disabled and those are just the ones I can think of without trying.
https://puri.sm/learn/intel-me/
https://blog.system76.com/post/168050597573/system76-me-firm...
https://m.hexus.net/tech/news/systems/112835-dell-now-offers...
As far as risk goes, the risk is very small and my personal opinion is that hardware is not worth replacing unless you are worried about being the target of a state-level actor who will spend the resources to gain clandestine physical access to your machine in order to surveil you.
ME attacks require a level of sophistication that is only worth it to a small number of entities pursuing extremely important targets.
That's basically an admission that the ME is a backdoor, and calling ME-free systems something any individual can purchase is farcical or malicious.
https://en.wikipedia.org/wiki/Intel_Management_Engine#Commer...
I have, right now, in my lab, multiple systems with ME disabled. I do not work for the government, military, or any intelligence agency.
Dell systems that have ME disabled come with a sticker of the number "3" on them, and linux tools exist that can verify the fact that it has been disabled.
My Precision 7760 mobile workstation can be purchased with ME disabled and it is listed as a BTO option at: https://www.dell.com/en-us/shop/workstations-isv-certified/p...
Scroll down to "System Management". "vPro disabled" == "ME disabled"
The fact is that modern processors/computers are so complex that it's simply not practical to build one without some kind of initialization and management processor or other programmable device. Intel, AMD, ARM, it doesn't matter. Any processor of this size will have at least one if not more management processors.
Maybe these companies could do better and release the source code of what runs on these management engines, and I would argue they should. But unless we want to go back 10 years in processor complexity and performance, the "Backdoors" as you call them aren't going anywhere.
Of course it can have security flaws, complexity that should not be required, etc, but I would expect with these messy things that it would also waste energy on unneeded features, too.
What is needing, is computer system that does not have such features. I do not know if this will be possible as a PC with 64-bit capabilities, unless perhaps it is using RISC-V for 64-bit capabilities (in which case it is a not a "PC with 64-bit capabilities", I suppose, but rather two separate systems). An open-source implementation may be usable, possibly using emulation or FPGA for 16-bit x86 real mode, and for PC BIOS capabilities if needed. However, it is then not 64-bit x86, which means that a specialized booting is needed if you want to run operating systems other than DOS. (Another alternative is to not implement PC at all, which may also be suitable for some uses.)