Two Hidden Instructions Discovered in Intel CPUs Enable Microcode Modification

And even if you actually have a backdoor on your PC, for hackers to exploit it, they somehow need to get to your local network first, which is not that easy on a home network unless your computer is the one to initiate the connection. I also probably won't work on anything but the built-in Ethernet port.

I don't know what "field day" hackers had, but I suspect it only helped them compromise corporate networks they could access where IME remote control (vPro?) was actively used. It is indeed a serious concern and warrants a recall, but I've yet to see how it can be a concern to most individuals, at least compared to OS-level attacks. And if it is, firewalls, including the simple ones in home routers should be effective.

AFAIK vPro doesn't let anything talk to its management interface over the network until you actually do the local setup.

I found this out to my irritation, when I once acquired a used workstation with vPro, freshly wiped, and — thinking I could just set it up by plugging its management-network NIC into my switch and talking to it over the LAN — I found out to my dismay that it wouldn't even bother to acquire an IP address for the management interface until I enabled vPro in the BIOS and then told it to use DHCP.

(Am I wrong about this? Perhaps, do OEMs ship batches of machines with vPro pre-configured in certain ways, for clients that explicitly specify that they're going to use vPro for remote provisioning? Or does every workstation order have an implicit "unload from the pallet, plug into a KVM, enable vPro, then install at location" step?)

So the question becomes whether you can access those registers, or otherwise affect the fuse loading process, using these features. That depends on the design (e.g. whether those registers are accessible and not locked down after initial load).

Fuses (and antifuses) are the only form of nonvolatile, programmable memory available in these process nodes (as they require no extra masks or processing steps beyond a regular CMOS process), that is why they are used. They are write-once memory, and they are based on breaking or making electrical connections, but they are not literally used to directly reconfigure chip wiring; that hasn't been the case for many years now. Modern fuse memory is just one more functional block you throw into your chip, and it comes with its own requirements, read amplifiers, etc (the fuses aren't actually "binary"; what happens is the electrical resistance increases, but you still need some analog-ish circuitry to set threshold levels to read them reliably, and carefully controlled programming voltages and timings, etc).

https://bit-tech.net/news/tech/cpus/intel-overclocking-block...

Before microcode - full overclock, after microcode update - locked multipliers.

The point is this isn't a bug, it's a feature; if you've gotten the CPU into red unlock anyway, you are already thoroughly screwed. This is like saying if you install a development version of an OS and enable remote debugging, you can take over the machine remotely. Well.... yes.

This is interesting because it's undocumented, not because it has security implications.

Does this require something other than writing the file to the UEFI partition, setting it as the next boot target, and rebooting into that boot target? I tend to think I misunderstand because that would require root privileges under Linux but not physical access.

They already have persistent and unlimited access to the ultimate back door and modifying the microcode isn't going to get them any extra access to your data or programs.

No. The article mentions that the key required to decrypt microcode updates can be extracted. http://inertiawar.com/microcode/ indicates that the encrypted microcode image is also signed, and being able to decrypt the image doesn't mean you can also generate an appropriate signature.