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: 14599
Joined: 2014-07-21
And ..."However, as spotted by Hardware Unboxed, the paper also says that "Additional funding was provided by generous gifts from Intel.
Any opinions, findings, and conclusions or recommendations expressed in this paper are those of the authors and do not necessarily reflect the views of the funding parties."
Gifts from Intel everywhere (and Nvidia ofc)
Though I tend to question research funded by corporate competitors, we are talking about a college here and not an "independent security research firm". This is very different from when CTS Labs tried to tank AMD's stock price. I would be more concerned about the funding from governments than Intel, but I guess you missed that part of the disclosure.
Yeah, funding by Intel, that's true. But to be frank, first, they uncovered Intel issues and vulnerabilities. So I guess, when in doubt, spend some trust on them to reveal issues of both companies, not just Intel (which they did months before this), and now AMD. Also, they are giving away their expertise to warn about such issues ahead of time, not to manipulate current stocks, as AMD, mentioned in the paper, was told about it, just like Intel was informed about their CPU issues ahead of time.
Senior Member
Posts: 1779
Joined: 2014-08-15
^ Yeah its not a drama to have funds from anyone who help your research and findings.
(Tom's Hw became intel or nv lapdogs.)
Junior Member
Posts: 1
Joined: 2020-04-25
Is there any way to recover encrypted data?
Senior Member
Posts: 7424
Joined: 2012-11-10
Are you asking in the hypothetical situation where your data is encrypted for ransom? Because the simple answer is yes: you need the decryption key (and the software that encrypted it in the first place). The easiest solution is to pay the ransomware and hope the scammer doesn't just take your money and run. The not-so-easy solution is to brute-force hack the encryption key. Depending how it was encrypted, this might not even be worth the effort. Modern keys are not meant to be hacked so easily.
Whether your data gets corrupt, deleted, infected by a virus, or held for ransom, the best way to recover anything is always regular backups. It's not something people like to hear, but think of it like preventative maintenance.
Posts: 22469
Joined: 2008-07-14
Somebody wants a bug for AMD in this mess of Intel bugs?
Here ya go: https://mlq.me/download/takeaway.pdf
You're welcome ...
Nobody wants bugs at all....but there's no reason to ignore one that's been published, regardless of how insignificant it is.