4

In a recent attack to INTEL-SA-00086, the researchers are able to extract the secret key that encrypts updates to various Intel CPUs.

In the arstechnica blog it is mentioned as

The key may also allow parties other than Intel—say a malicious hacker or a hobbyist—to update chips with their own microcode, although that customized version wouldn’t survive a reboot.

In theory, it might also be possible to use Chip Red Pill in an evil maid attack, in which someone with fleeting access to a device hacks it. But in either of these cases, the hack would be tethered, meaning it would last only as long as the device was turned on. Once restarted, the chip would return to its normal state. In some cases, the ability to execute arbitrary microcode inside the CPU may also be useful for attacks on cryptography keys, such as those used in trusted platform modules.

  • How someone can upload the firmware without the private key? Isn't it require a signature check?

  • How can we sure that our shipped CPU is not hacked by a third party?

kelalaka
  • 5,409
  • 4
  • 24
  • 47

1 Answers1

4

Yes, it is bypassed

According to the CVE-2018-3659 and CVE-2018-3643 whitepaper, the Intel® Converged Security Mangement Engine's System on a Chip has four different DFx (Design For testability, debug, security and validation) states:

  1. Green (DFx locked) - normal state
  2. Orange (DFx unlocked) - allows to debug OEM IPs
  3. Red (DFx unlocked) - allows Intel to debug ALL IPs
  4. DAM (Delayed Authentication Mode) - special state in which debug interfaces are still closed

The INTEL-SA-00086 vulnerability uses a buffer overflow in the file handling of Intel Management Engine's file system to change the DFx state to Red unlocked, which later allows the attacker to disable firmware signature checks for as long as the DFx state remains.

The detailed steps to reproduce it can be seen in the published Proof of Concept.

We can be relatively sure the CSME firmware hasn't been hacked by third parties (at least without Intel's consent) because it is the RC4 microcode encryption key what has been broken, NOT the firmware signing key. When the computer reboots, the DFx state goes back to Green locked and, if there are persistent changes, the firmware signature check fails as the signing public keys' hashes are embedded in ROM during the manufacturing process and cannot be rewritten. Newer related vulnerabilities could be discovered, though.

Albert Gomà
  • 434
  • 2
  • 10