feature article
Subscribe Now

Security Flaw Afflicts Intel x86 Boot ROMs

CVE-2020-8705 Undermines Intel’s Boot Guard Security

Another year, another Intel bug. 

What makes this bug interesting is that it’s so crafty. It’s fun to see what loopholes hardware and software can discover all by themselves. If you’re a homeowner, you know that water is amazingly devious. It can intrude anywhere, including moving uphill, through tiny holes, and along porous surfaces. Stopping leaks – or finding bugs – feels like a never-ending chore. 

In this case, an Intel bug fix introduced a new bug. Ironic? Sure, but, to be fair, Intel’s x86 processors are insanely complex while also being wildly popular. That’s a combination guaranteed to uncover flaws.

The bug in question is officially being called CVE-2020-8705 and it involves corrupted boot ROMs. We’ve all become familiar with the concept of a root of trust as a way to ensure that everything in your software stack, from the boot ROM all the way up to your drivers and applications, are all legitimate. The process usually involves each layer of software vouching for the security of the next layer. Your hardware checks that the firmware is okay before executing it, then the firmware checks the operating system, which then checks its drivers, and so on. 

We’re also all familiar with the concept of race conditions. Unwanted race conditions usually happen in hardware, but there can be software races, too. Maybe a software semaphore is set by one process at the very moment that another process is checking it, so the two wind up disagreeing on the status. 

CVE-2020-8705 combines the root of trust with race conditions to uncover a situation where evildoers can corrupt your boot ROM and unlock secrets you thought were safely hidden away. The good news is, exploiting the bug requires physical access to the hardware. It can’t be attacked remotely. The bad news is, it affects nearly all Intel x86-based machines, regardless of operating system. It’s not specific to Windows or Linux or MacOS. It’s baked into the silicon, and it’s hard – perhaps even impossible – to fix. 

Here’s what happens. All x86 processors have a sleep mode. In fact, they have several. A commonly used sleep mode is S3, and it’s usually activated when you close the lid on your laptop or when a software timer triggers sleep after a period of inactivity. In S3 sleep, the processor is completely dead but the system DRAM stays alive. All CPU state is lost, but all memory contents are preserved. The idea is to save power while also enabling a quick restart when you open your laptop, wiggle your mouse, or tap your screen. Rather than doing a complete cold reboot, the machine simply wakes the processor and resumes where it left off. 

But because the processor was shut down, it needs to boot up and be reinitialized. The process is about 90% the same as for a cold boot, but without disturbing the contents of RAM. Most, but not all, of the code path is the same. Resuming from sleep is faster – that’s the whole point – because it skips a few steps. In particular, a cold boot will verify that the boot ROM is valid, but a wake from sleep won’t, on the assumption that the boot ROM hasn’t changed since the computer went to sleep. 

But what if it has changed? 

Security researcher Trammell Hudson discovered that UEFI boot ROMs don’t perform a root-of-trust check when they awaken from sleep mode. After all, the computer was never turned off, so how could the ROM have changed? Even though it’s possible (common, in fact) to update the flash BIOS while the computer is powered-up, the update process checks the validity of the new firmware and re-establishes the root of trust. But if there hasn’t been a reflash, and there hasn’t been a cold shutdown, the firmware must still be valid, right? 

Not if you have a chip clip and a malicious mind. Trammell showed that it’s possible to reflash the boot ROM while the system is in sleep mode. When the machine reawakens, it bypasses all the usual security checks and runs whatever new firmware you’ve loaded. And, since system RAM is undisturbed, the first thing your malicious code might want to do is to scan memory for interesting information, such as decryption keys. Windows and Linux both store their disk-encryption keys in RAM, which means they’re preserved during sleep mode and therefore accessible to malicious firmware. 

Hacking a machine in this way does require physical access to the boot ROM, but that’s not difficult with most laptops, and it’s even easier with desktop or server enclosures. If you can reach the boot ROM’s SPI interface pins, you’re in. Microsoft’s Surface Pro tablets and other tightly packed consumer systems might be immune simply because they’re impossible to open. Or, at least, they can’t be opened and then closed back up again, so don’t plan on being sneaky. 

Trammell describes this as “a classic time-of-check / time-of-use (TOCTOU) error” It’s a slow-motion race condition between when the boot ROM is verified (at cold boot) and when that supposedly secure code is executed (while exiting sleep mode). There’s no way to guarantee that the code you’re executing is the same code you just checked. There’s always a finite time delay between the two events. 

Sadly, there would have been a trivially easy fix for this, but it seems to have fallen victim to corporate politics and marketing. Systems that use Intel’s platform controller hub (PCH) chip have one-time programmable fuses specifically intended to enable/disable speedy resume-from-sleep restarts. Leaving the fuses intact forces the processor to do a complete reboot, including all security checks, when it resumes from S3 sleep mode. Blowing the fuses enables the quicker restart but bypasses the security checks. Guess which mode nearly every hardware OEM uses? 

In part that’s because Microsoft encourages it. The company designed Windows 10 to restart quickly, in part to better compete with new mobile operating systems like iOS and Android that don’t suffer from Windows’s lengthy and convoluted boot-up procedure. Windows OEMs are strongly encouraged to keep restart times under 2.0 seconds, and that pretty much requires warm-start shortcuts. Which means blowing the PCH fuses, which means the option is irreversible. 

What’s the fix? If you’re not using Intel’s PCH support chip, you should be able to enable full security checks when exiting S3 sleep mode. That way, your boot ROM is checked every time it’s used, not just on cold starts. Warm starts will take longer, but they’ll be more secure. 

If you are using Intel’s PCH, the next best option is to deploy Intel’s firmware workaround. The company isn’t saying exactly what the newer version does, except to suggest that it improves security. Trammell theorizes that it ignores the one-time programmable fuses in the PCH and uses its own switch instead. 

Ominously, he also points out that “This workaround also points to a weakness in the OTP fuses.” So, the fix for the fix may need a fix. The root of trust starts a very long chain, indeed. 

One thought on “Security Flaw Afflicts Intel x86 Boot ROMs”

Leave a Reply

featured blogs
May 24, 2022
Today is going to be my monthly update. This normally runs on the last Friday of the month, but that's a Cadence Global Recharge Day, so we will all be off. For various other reasons, I need to... ...
May 20, 2022
I'm very happy with my new OMTech 40W CO2 laser engraver/cutter, but only because the folks from Makers Local 256 helped me get it up and running....
May 19, 2022
Learn about the AI chip design breakthroughs and case studies discussed at SNUG Silicon Valley 2022, including autonomous PPA optimization using DSO.ai. The post Key Highlights from SNUG 2022: AI Is Fast Forwarding Chip Design appeared first on From Silicon To Software....
May 12, 2022
By Shelly Stalnaker Every year, the editors of Elektronik in Germany compile a list of the most interesting and innovative… ...

featured video

Building safer robots with computer vision & AI

Sponsored by Texas Instruments

Watch TI's demo to see how Jacinto™ 7 processors fuse deep learning and traditional computer vision to enable safer autonomous mobile robots.

Watch demo

featured paper

Introducing new dynamic features for exterior automotive lights with DLP® technology

Sponsored by Texas Instruments

Exterior lighting, primarily used to illuminate ground areas near the vehicle door, can now be transformed into a projection system used for both vehicle communication and unique styling features. A small lighting module that utilizes automotive-grade digital micromirror devices, such as the DLP2021-Q1 or DLP3021-Q1, can display an endless number of patterns in any color imaginable as well as communicate warnings and alerts to drivers and other vehicles.

Click to read more

featured chalk talk

Flexible Power for a Smart World

Sponsored by Mouser Electronics and CUI Inc.

Safety, EMC compliance, your project schedule, and your BOM cost are all important factors when you are considering what power supply you will need for your next design. You also need to think about form factor, which capacitor will work best, and more. But if you’re not a power supply expert, this can get overwhelming in a hurry. In this episode of Chalk Talk, Amelia Dalton chats with Ron Stull from CUI Inc. about CUI PBO Single Output Board Mount AC-DC Power Supplies, what this ac/dc core brings to the table in terms of form factor, reliability and performance, and why this kind of solution may give you the flexibility you need to optimize your next design.

Click here for more information about CUI Inc PBO Single Output Board Mount AC-DC Power Supplies