Though that’s a separate chip on the motherboard obviously that would have access to everything a bad actor would need to know: what’s being sent to and from the CPU, memory, USB, network, everything and where it was going to/from.
That’s different to a back door on the CPU itself
Also, it wasn’t a back door. It was an advertised feature of the motherboard. The management engine has a separate network interface (RJ-45 jack) and it is supposed to be connected to a secure internal network that doesn’t have access to the internet. There were articles in the trade press about how that can be insecure if you don’t do that. I suspect the Forbes writer saw those articles and misunderstood what they were saying.
If you don’t plug anything into the management port, it is absolutely secure. Well, as secure as the OS by itself is anyway.
But these days a CPU is like a motherboard. System-on-a-chip is not just for low power computers. There are lots of things on the same die as the CPU that used to be separate chips. I believe the current management engine that Intel uses is a small 486 CPU that lives inside the big CPU.
Certainly a supply chain attack, like adding an extra chip to a motherboard, is easier for a third party to perform than for a third party to somehow sneak a back door into an Intel or AMD cpu.
Intel or AMD (or Apple, Qualcomm, etc.) putting a backdoor into their own CPUs is all that the management engine is. It is supposed to allow enterprise management of systems, but tin foil hats say that the NSA can use it to access your computer. The black hats say that any security flaw in the management engine means hackers can use it to access your computer.
Some do, but others piggy back on the primary NIC. I have and use systems with both designs. All of the systems I have that are sold as servers use a BMC (baseboard management controller, if spelling it out helps at all) which gets its own IP address, even when sharing a NIC.
The desktop systems with the AMT management engine just intercept traffic sent to a particular port at the host system’s IP. That is the old AMT/vPro setup. I’m not sure exactly how it is being done now, but it still over a single NIC.
The particular ones in the Forbes article that was talking about Supermicro motherboards do have a separate network interface. Systems like Intel VPro are a different beast, and insecure in different ways.
There is a bit of a disconnect in the above about CPU as central processing unit, versus the big honking die holding a large fraction of a computer’s implementation of modern systems.
An x386 was implemented with 275,000 transistors. There was nothing but a single pipeline engine running instructions. Everything else was implemented in other chips. Cache was off die, for those systems that actually had cache. Even back then there were discussions about potential back doors or exploits. Exploits that might take advantage of timing issues, for instance, that could lead to incorrect execution of an instruction. Something that could be parleyed into a privilege escalation.
That required the attacker to be running on the machine, albeit in unprivileged mode.
A modern computer is more and more a system on a chip. The majority of computers in our lives are already so. The PC on our desk is in some ways more the dinosaur.
The number of actual fully functional processors inside a modern computer is way more than most realise. Every device is typically internally controlled by processors of significant capacity. A modern OS spends most of its time chatting with devices at a very high level. Something as innocuous as a NIC, likely contains a number of processors, one managing the low level interface, right down to signal processing on the wire, another likely contains a protocol engine for Ethernet, and useful ones a good fraction of TCP/IP. There is space and capacity to place a Trojan of near arbitrary wickedness.
Modern SOCs bring this entire subsystem onto the CPU die. Which brings it under the control of the CPU designer. Although such subsystems may be an older design, just reworked for the lastest design rules.
Risks exist not in the gates doing the work, but in the firmware. One would assume robust integrity checks are employed to prevent the most egregious of malware injection. Modifying on chip firmware is always much easier than trying to modify gate logic, but hopefully easier to detect.
But nothing is perfect. From the point of view of malware, the now defunct Underhanded C Contest, was a fabulous example of how really clever coding could inject bad behaviour into code that was, on the surface, blameless; would pass a code inspection and usually work correctly. Enough to pass a test suite. But still evil enough for nefarious purposes.
Imagine a code integrity check that always produces the correct answer except for when presented with a specially crafted input stream, that input just happens to trigger a flaw resulting from (say) a bad pointer cast leading to dropped a bit, and from there it accidentally outputs a hash value derived from only a tiny fragment of the input stream. Thus allowing crafting of an executable image that will always hash to a desired value, despite its actual contents. This is another example of the difficulty in the chain of trust. Multiple implementations with different tool chains is a start. Sadly a lot of code out there doesn’t manage this.
The XZ Utils back door was an example of a highly sophisticated attack that leveraged a range of techniques from social engineering to unexpected interactions in the OS to potentially delivering a devastating security threat across the planet.
A compromised NIC would be close to a nightmare scenario.
Chip designer. That would have been me. I mentioned that we could tell when the chips were powered down - we could even tell the altitude of where the chip was (actually this was from the board) which came in handy when RAM was failing and we wanted to see if cosmic rays might be a cause.
In fact there is a name for this - phone home. It was turned off for all systems installed in government facilities.
So, it is trivial to install all kinds of monitors etc, and test modes, in chips you design. I was talking about fabs doing it for chips designed elsewhere. Big semiconductor makers have too much to lose by ripping off customers or exposing data. A Chinese government owned fab, say, not so much.
Practically speaking, not quite. Few people design SoCs from scratch. You buy IP (Intellectual Property) from a trusted source - you hope. The IP can sometimes be in the form of RTL so you can synthesize it with the rest of your chip, but it is often laid out blocks using a specific fab’s technology and design rules, which you plop into your design and hook up. The question is whether this IP is safe. I doubt many designers verify a laid out block, and you may get a gate level or RTL description but you are unlikely to verify it against the laid out block.
Guys who write papers about this stuff excel at paranoia. A recent spate was how to handle designing when you can’t trust anyone. They’re the doomsday preppers of the electronics biz, but there seems to be grant money in it.
So this has been an interesting read, though I haven’t much to add since I’m miles from being a chip designer.
I don’t think I’ve seen the other half of the question answered:
If some company put a secret beck door into a chip, how hard would it be for a sophisticated user, like the US, China, or another chip company to figure that out on their own? That is, no expose by an insider.