New Intel Vulnerability found, Converged Security and Management Engine exploitable
It seems Intell cannot catch a break when it comes to vulnerabilities, as yes a new one has been discovered. For this one, you need physical access to the computer though.
A vulnerability has been found in the ROM of the Intel Converged Security and Management Engine (CSME). This vulnerability jeopardizes everything Intel has done to build the root of trust and lay a solid security foundation on the company's platforms. The problem is not only that it is impossible to fix firmware errors that are hard-coded in the Mask ROM of microprocessors and chipsets.
ptsecurity posted a really in-depth post on the exploit, which we'll add here:
Positive Technologies specialists have discovered an error in Intel hardware, as well as an error in Intel CSME firmware at the very early stages of the subsystem's operation, in its boot ROM. Intel CSME is responsible for initial authentication of Intel-based systems by loading and verifying all other firmware for modern platforms. For instance, Intel CSME interacts with CPU microcode to authenticate UEFI BIOS firmware using BootGuard. Intel CSME also loads and verifies the firmware of the Power Management Controller responsible for supplying power to Intel chipset components.
Even more importantly, Intel CSME is the cryptographic basis for hardware security technologies developed by Intel and used everywhere, such as DRM, fTPM, and Intel Identity Protection. In its firmware, Intel CSME implements EPID (Enhanced Privacy ID). EPID is a procedure for remote attestation of trusted systems that allows identifying individual computers unambiguously and anonymously, which has a number of uses: these include protecting digital content, securing financial transactions, and performing IoT attestation. Intel CSME firmware also implements the TPM software module, which allows storing encryption keys without needing an additional TPM chip—and many computers do not have such chips.
Intel tried to make this root of trust as secure as possible. Intel's security is designed so that even arbitrary code execution in any Intel CSME firmware module would not jeopardize the root cryptographic key (Chipset Key), but only the specific functions of that particular module. Plus, as the thinking went, any risks could be easily mitigated by changing encryption keys via the security version number (SVN) mechanism. This was demonstrated in 2017, when an arbitrary code execution vulnerability was found in the BringUP (bup) firmware module, as described in Intel SA-00086. At that time, Intel simply generated new keys by incrementing the SVN, easily preventing any compromise of EPID-based technologies.
Unfortunately, no security system is perfect. Like all security architectures, Intel's had a weakness: the boot ROM, in this case. 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.
The EPID issue is not too bad for the time being because the Chipset Key is stored inside the platform in the One-Time Programmable (OTP) Memory, and is encrypted. To fully compromise EPID, hackers would need to extract the hardware key used to encrypt the Chipset Key, which resides in Secure Key Storage (SKS). 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.
The vulnerability discovered by Positive Technologies affects the Intel CSME boot ROM on all Intel chipsets and SoCs available today other than Ice Point (Generation 10). The vulnerability allows extracting the Chipset Key and manipulating part of the hardware key and the process of its generation. However, currently it is not possible to obtain that key's hardware component (which is hard-coded in the SKS) directly. The vulnerability also sets the stage for arbitrary code execution with zero-level privileges in Intel CSME.
We will provide more technical details in a full-length white paper to be published soon. We should point out that when our specialists contacted Intel PSIRT to report the vulnerability, Intel said the company was already aware of it (CVE-2019-0090). Intel understands they cannot fix the vulnerability in the ROM of existing hardware. So they are trying to block all possible exploitation vectors. The patch for CVE-2019-0090 addresses only one potential attack vector, involving the Integrated Sensors Hub (ISH). We think there might be many ways to exploit this vulnerability in ROM. Some of them might require local access; others need physical access.
As a sneak peek, here are a few words about the vulnerability itself:
- The vulnerability is present in both hardware and the firmware of the boot ROM. Most of the IOMMU mechanisms of MISA (Minute IA System Agent) providing access to SRAM (static memory) of Intel CSME for external DMA agents are disabled by default. We discovered this mistake by simply reading the documentation, as unimpressive as that may sound.
- Intel CSME firmware in the boot ROM first initializes the page directory and starts page translation. IOMMU activates only later. Therefore, there is a period when SRAM is susceptible to external DMA writes (from DMA to CSME, not to the processor main memory), and initialized page tables for Intel CSME are already in the SRAM.
- MISA IOMMU parameters are reset when Intel CSME is reset. After Intel CSME is reset, it again starts execution with the boot ROM.
New Intel Roadmap leaks: 10 core Comet lake in 2020, Rocket Lake on 2021, both at 14nm - 04/25/2019 07:46 AM
Two roadmaps from Intel have leaked, and they show some interesting information. First up is are Comet lake based processors with up-to ten cores. Intel would be releasing these in 2020 and they are f...
Intel Teases Its New Intel Graphics UI - 03/13/2019 08:39 AM
Intel has released a teaser video that shows off the new Intel Graphics UI with an announcement of "Coming this month." ...
Windows 10: New Intel Microcode for Spectre V3a, V4 & L1TF Gets Released - 11/28/2018 06:15 PM
Microsoft began rolling out Intel's new countermeasure code against the Spectre V3a, Spectre V4 and L1TF vulnerabilities through Windows Update. It starts with a patch for the latest version of Wind...
Researchers Discover new Intel processor Vulnerability - the BranchScope Attack - 03/28/2018 01:58 PM
A new Vulnerability has been discovered on Intel processors by researchers. The security attack uses the speculative execution features of modern processors to leak sensitive information and underm...
New Intel Coffee Lake Processor Prices Pop Up at US Webshops - 02/21/2018 10:42 AM
We've discussed the new batch of Coffee Lake processors a bunch of times already including some Canadian etailer leaks, however, more prices (USA) have been showing up at retailers, these include ...
Senior Member
Posts: 7424
Joined: 2012-11-10
You park your car at work and start walking to your office building. You look down and see a shiny new 32GB thumb drive lying on the path. You think someone must have dropped it, so you pick it up, put it into your pocket, and go up to your office.
Since you’re a good human being, you want to return it to whoever lost it, in case there are important work documents or someone’s novel-in-progress on there. So, you do what most people would do and plug it into your computer in the hopes of finding something on the drive that identifies the owner.
This, my friend, is what’s known in the world of infosecurity as a ‘candy drop’ - an intentionally placed USB device dropped in plain sight, which tempts a target to pick it up and plug it in.
Run a Linux live CD/USB to open it up. Not only will it not run any automated binaries, but even if it does, you've basically got a sandbox OS running entirely in RAM for it to destroy instead of anything actually important. If you find it was honestly someone's missing drive, great - you get to return it. If you find it was a ploy to steal your information or ruin your day, great - just format the drive and now you've got a 32GB drive for free.
Win-win.
Senior Member
Posts: 259
Joined: 2015-06-17
Case with teeth? That sounds like guru3D case of the month material!
Senior Member
Posts: 14065
Joined: 2013-01-17
Hey, do you know a guru CrazY_Milojko by chance? I miss him...
Senior Member
Posts: 14065
Joined: 2013-01-17
Run a Linux live CD/USB to open it up. Not only will it not run any automated binaries, but even if it does, you've basically got a sandbox OS running entirely in RAM for it to destroy instead of anything actually important. If you find it was honestly someone's missing drive, great - you get to return it. If you find it was a ploy to steal your information or ruin your day, great - just format the drive and now you've got a 32GB drive for free.
Win-win.
What about malware firmware? (Or even a spying SoC instead of plain USB electronics...)
PS Nice name for a music band "Malware Firmware", eh?
Senior Member
Posts: 6080
Joined: 2003-04-05
Intel, the gift that keeps on giving.