Researchers with the security firm Positive Technologies have discovered a significant flaw in Intel chipsets dating back at least five years. The flaw is reportedly completely unfixable because it’s hard-coded into the mask ROM, making it impossible for Intel to update. It may also allow hackers to bypass any downstream attempt to secure the machine, including secondary processors like Apple’s T2 security chip.
The flaw Positive Technologies found is in Intel’s Converged Security and Management Engine (CSME), which is fundamental to the boot authentication process. Features like Intel’s DRM implementation, Intel Identity Protection, and Intel’s TPM all rely on the CSME. Here’s how Positive Technologies describes the problem in aggregate:
An early-stage vulnerability in ROM enables control over reading of the Chipset Key and generation of all other encryption keys. One of these keys is for the Integrity Control Value Blob (ICVB). With this key, attackers can forge the code of any Intel CSME firmware module in a way that authenticity checks cannot detect. This is functionally equivalent to a breach of the private key for the Intel CSME firmware digital signature, but limited to a specific platform…
However, this key is not platform-specific. A single key is used for an entire generation of Intel chipsets. And since the ROM vulnerability allows seizing control of code execution before the hardware key generation mechanism in the SKS is locked, and the ROM vulnerability cannot be fixed, we believe that extracting this key is only a matter of time. When this happens, utter chaos will reign. Hardware IDs will be forged, digital content will be extracted, and data from encrypted hard disks will be decrypted… However, currently it is not possible to obtain that key’s hardware component (which is hard-coded in the SKS) directly.
Firmware updates provided by Intel a year ago were intended as a partial solution to this problem. A year ago, Intel patched CVE-2019-090, an exploit that allowed an attack against the CSME through the Integrated Sensors Hub (ISH). Intel and the researchers are taking different views on this topic, with Intel arguing that an attacker effectively requires physical access to the machine in order to carry out this threat. For its part, Positive Technologies acknowledges in its own blog post that the chipset key extraction hasn’t actually been carried out yet, but is emphasizing that this is an attack against the heart of the CPU that can’t be mitigated, updated, or prevented.
What Constitutes a Threat?
Humans are bad at judging threats. Numerous articles in the past few weeks have pointed out that the coronavirus, while a genuine public health emergency, is highly unlikely to emerge as the Spanish Flu 2.0. We tend to pay more attention to novel or unusual events than to regular ones, even when the risk involved is statistically quite small. People pay far more attention to plane crashes than car crashes, even though car crashes kill orders of magnitude more people than planes do.
Positive Technologies is emphasizing the fact that this vulnerability is conceptually massive. Break the CSME, and you’ve got full control of the system. While I haven’t seen anyone from Positive Technologies affirmatively state this, it doesn’t seem likely that even a dedicated security processor like Apple’s T2 can prevent this issue. If the security flaw can be initialized in the boot ROM, anything loaded afterward can be tainted.
Intel is emphasizing the fact that the attack is spectacularly unlikely to represent a practical, real-world threat. According to Intel, it already pushed code to prevent this kind of local attack from succeeding and, provided your motherboard/laptop manufacturer pushed a firmware update, you should already be protected.
While it’s true that the chipset keys are common to a given platform generation, no chipset keys have actually been decrypted and extracted from an Intel platform and the process for doing so is decidedly non-trivial. Intel is emphasizing that the only way an attacker could practically abuse this vector is if they have physical access to the machine. Physical machine access is often treated as a de facto boundary in IT security, meaning that if someone has it, they can probably find a method of breaching the platform.
For once, these issues have nothing to do with Meltdown and Spectre, but they are another conceptual example of this type of risk perception problem. For all the writing done on these topics and their associated security flaws, no real-world attacks have actually attempted to use Meltdown or Spectre. Given that it’s been more than two years, we can safely assume that if commercial black hats were going to use them, they would’ve. That doesn’t mean these sorts of attacks aren’t real, but the groups they appeal to are nation-states and commercial espionage groups, not your typical author of online malware.
Intel’s repeated security issues over the past few years have collectively harmed its reputation among some users. I’m not going to say they shouldn’t have, given that some fixes have carried performance penalties and some users were made meaningfully less secure as a result of these bugs, even if the number is small in absolute terms. Every silicon vendor has a responsibility to ship bug-free products and Intel is no exception.
But as a matter of practical threat or risk, these CSME bugs aren’t likely to cause problems for anyone in their day-to-day lives. This is particularly true if practical exploitation requires physical device possession. Positive Technologies’ comments on how “utter chaos will reign,” as though this is a likely and/or inevitable outcome, may not be a well-supported framing of the actual risk.
- Intel Expects to Reach Process Parity With 7nm in 2021, Lead on 5nm
- Intel Refreshes Cascade Lake Xeons: Significantly Lower Pricing, Higher Core Counts
- Intel Patches Zombieload Security Threat Again