Hackers Can Use Just-Fixed Intel Bugs To Install Malicious Firmware On PCs
As the amount of sensitive data stored on computers has exploded over the past decade, hardware and software makers have invested increasing amounts of resources into securing devices against physical attacks in the event that they’re lost, stolen, or confiscated. Earlier this week, Intel fixed a series of bugs that made it possible for attackers to install malicious firmware on millions of computers that use its CPUs.
The vulnerabilities allowed hackers with physical access to override a protection Intel built into modern CPUs that prevents unauthorized firmware from running during the boot process. Known as Boot Guard, the measure is designed to anchor a chain of trust directly into the silicon to ensure that all firmware that loads is digitally signed by the computer manufacturer. Boot Guard protects against the possibility of someone tampering with the SPI-connected flash chip that stores the UEFI, which is a complex piece of firmware that bridges a PC’s device firmware with its operating system.
Hardware-enforced security
These types of hacks typically happen when attackers attach hardware to the insides of a computer and use Dediprog or similar chip programming tools to replace authorized firmware with malicious firmware.
As Intel explains here:
UEFI BIOS code execution is generally untethered to the underlying hardware, which means this UEFI BIOS code runs without being verified or measured. Hence, this makes the entire boot process vulnerable to subversion of the BIOS, whether that can happen through an unprotected update process or simple hardware attacks using SPI flash memory replacement or using a Dediprog.
Intel Boot Guard provides robust hardware-enforced boot policy controls to platform manufacturers and platform owners to authorize which BIOS code is allowed to run on that platform. Intel Boot Guard provides that hardware based Root-of-Trust (RoT) for platform boot verification, which is responsible for verifying the BIOS image prior to BIOS execution. Intel Boot Guard raises the security bar of the platform, reducing the above attack vectors and making it harder to launch attacks to subvert the boot process.
Early this year, security researcher Trammell Hudson discovered three vulnerabilities that prevented Boot Guard from working when a computer comes out of sleep mode. Known technically as S3, this mode preserves all items stored in computer memory but shuts off the CPU entirely.
Subverting Boot Guard
An attacker who is able to bypass Boot Guard during wakeup would then be able to carry out a host of malicious activities. Chief among them is obtaining the keys used to encrypt hard drives, as long as the keys are stored in memory, as they are with many computers during sleep. With that, an attacker could obtain the decrypted versions of all data stored on the computer without requiring the user’s password.
An attacker could also infect the machine with a rootkit—malicious code that’s difficult or impossible to detect—that would run in system management mode until the next reboot. Such SMM implants are the kind of thing the NSA is reported to have.
While these types of exploits are serious, the attack scenarios are limited because the hack can’t be done remotely. For many people, attacks that require physical access aren’t a part of their threat model. It would also require hardware and firmware expertise and special tools such as the Dediprog or Spispy, an open source flash emulator Hudson has developed. In a writeup published this week, Hudson wrote:
Since CVE-2020-8705 requires physical access, it is harder for an attacker to use than a remote exploit. However, there are a few realistic attack scenarios where it could be used.
One example is when clearing customs at an airport. Most travellers close their laptop during descent and allow it to enter S3 sleep. If the device is taken by the adversarial agency upon landing, the disk encryption keys are still in memory. The adversary can remove the bottom cover and attach an in-system flash emulator like the spispy to the flash chip. They can wake the machine and provide it with their firmware via the spispy. This firmware can scan memory to locate the OS lock screen process and disable it, and then allow the system to resume normally. Now they have access to the unlocked device and its secrets, with no need to compel the owner to provide a password.
The adversary can also install their own SMM “Ring -2” rootkit at this point, which will remain resident until the next hard reboot. This could provide them with code execution on the system when it has moved to a trusted network, potentially allowing horizontal movement.
Another example is a hardware implant that emulates the SPI flash. The iCE40up5k [a small field-programmable gate array board] used in one of the variants of the spispy fits easily inside or underneath an SOIC-8 package, allowing a persistent attack against the resume path. Since the FPGA can easily distinguish between a cold boot and validation from the system resuming from sleep, the device can provide a clean version of the firmware with the correct signature when it is being validated or read by a tool like flashrom, and only provide the modified version during a resume from sleep. This sort of implant would be very difficult to detect via software, and if done well, would not look out of place on the mainboard.
The fix is in
One of the Boot Guard vulnerabilities stemmed from configuration settings that manufacturers literally burn into the CPU through a process called one-time programmable fuses. OEMs are supposed to have the option of configuring the chip to either run Boot Guard when a computer comes out of S3 or not. Hudson isn’t sure why all five of the manufacturers he tested had it turned off, but he suspects it’s because machines resume much more quickly that way.
In an email, an Intel spokeswoman wrote: “Intel was notified of a vulnerability affecting Intel Boot Guard in which a physical attack may be able to bypass Intel Boot Guard authentication when resuming from sleep state. Intel released mitigations and recommends maintaining physical possession of devices.”
Intel isn’t saying how it fixed a vulnerability that stems from fuse settings that can’t be reset. Hudson suspects that Intel made the change using firmware that runs in the Intel Management Engine, a security and management coprocessor inside the CPU chipset that handles access to the OTP fuses, among many other things. (Earlier this week, Intel published never-before-disclosed details about the ME here.)
The two other vulnerabilities stemmed from flaws in the way CPUs fetched firmware when they were powered up. All three of the vulnerabilities were indexed under the single tracking ID CVE-2020-8705, which received a high severity rating from Intel. (Intel has an overview of all November security patches here. Computer manufacturers began making updates available this week. Hudson’s post, linked above, has a far more detailed and technical writeup.
READ MORE HERE
