3 ms·

TL;DR 1. If you control Intel Management Engine (exploit/backdoor/whatever), you have full control over the system. 2. That full control comes with, among eve

TL;DR 1. If you control Intel Management Engine (exploit/backdoor/whatever), you have full control over the system. 2. That full control comes with, among everything else, the ability to put the CPU in a deep debug state ("Red Unlock") 3. In Red Unlock, you can basically play with the CPU's internals at will using a debug cable (just a modified A-A USB3 cable on many modern systems; "DCI"). 4. It turns out that in Red Unlock state there are also undocumented instructions that let you do the same thing straight from code running on the CPU itself. Notice how the security relevance stops at #1. We already know that if you control ME, you control the system. So there is no security impact to this discovery. The prerequisite is already total control. Also notice how what these instructions let you do isn't new. The same researchers already showed how to do the same thing via an external debugger (CRBUS access) last year. So this does not open any new capabilities for CPU research. What it does do is make things more convenient. Now you can do this without an external debugger, "only" with an ME patch/exploit and code running on the system itself, which means you could e.g. have it apply custom microcode patches on every boot (by patching your UEFI firmware to do it). Also, the USB debug thing doesn't work on all motherboards (some are missing the required connections), while this would work.

Lammy 5y ago
> Notice how the security relevance stops at #1. Security of a single PC, or security of an entire operation? Seems like this would be a great "in" for personalized unattended exploits of airgapped systems, kinda like what Stuxnet/Flame/Duqu were famous for but at an even lower level.
- marcan_42 5y ago
  You still need to compromise ME, at which point there are a million easier ways to accomplish your goals than a microcode patch. For example, SMM is much easier to compromise and arguably more powerful (you can hide large amounts of code in SMM, not so in microcode); SMM backdoors that interact with userspace code have already been demonstrated. Or you could do something in ME directly, which again has plenty more space to hide stuff in than microcode. 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.
  - Lammy 5y ago
    > because it's undocumented, not because it has security implications. "They're the same picture."
    - marcan_42 5y ago
      No. The Apple M1 is undocumented, but so far the only security problem I've found while reverse engineering it was an actual unintentional bug. It is otherwise extremely well-designed as far as security goes.

Lammy 5y ago

> Notice how the security relevance stops at #1. Security of a single PC, or security of an entire operation? Seems like this would be a great "in" for personalized unattended exploits of airgapped systems, kinda like what Stuxnet/Flame/Duqu were famous for but at an even lower level.

marcan_42 5y ago
You still need to compromise ME, at which point there are a million easier ways to accomplish your goals than a microcode patch. For example, SMM is much easier to compromise and arguably more powerful (you can hide large amounts of code in SMM, not so in microcode); SMM backdoors that interact with userspace code have already been demonstrated. Or you could do something in ME directly, which again has plenty more space to hide stuff in than microcode. 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.
- Lammy 5y ago
  > because it's undocumented, not because it has security implications. "They're the same picture."
  - marcan_42 5y ago
    No. The Apple M1 is undocumented, but so far the only security problem I've found while reverse engineering it was an actual unintentional bug. It is otherwise extremely well-designed as far as security goes.