CVE-2020-8705 allows a local attacker with physical access to the SPI
flash chip on a sleeping machine to perform a
Time-of-check/Time-of-use (TOCTOU) attack against Intel’s
Bootguard hardware root of trust and gain control of the
firmware when resuming from S3 sleep. It was patched by Intel as part
of INTEL-SA-00391 with the usual terse description:

CVEID: CVE-2020-8705
Description: Insecure default initialization of resource in Intel(R)
Boot Guard in Intel(R) CSME versions before 11.8.80, 11.12.80, 11.22.80,
12.0.70, 13.0.40, 13.30.10, 14.0.45 and 14.5.25, Intel(R) TXE versions
before 3.1.80 and 4.0.30, Intel(R) SPS versions before E5_04.01.04.400,
E3_04.01.04.200, SoC-X_04.00.04.200 and SoC-A_04.00.04.300 may allow
an unauthenticated user to potentially enable escalation of privileges
via physical access.
CVSS Base Score: 7.1 High
CVSS Vector: CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

Overview

When modern Intel x86 computers go to sleep, they enter what is called
“S3”. This mode maintains power to DRAM, but shuts off the CPU entirely.
All CPU state is lost and must be restored upon waking from S3. The cold
boot and warm resume start with the same code path in the SPI flash
(described in more detail below) and diverge
once the firmware recognizes that the system is resuming from sleep and
does not need to initialize the DRAM controller.

During a normal boot the firmware validates the contents of the SPI
flash are signed by the OEM, but this step is skipped on many platforms
during resume from S3. This allows a local attacker with physical access
to substitute their unsigned code in place of the official firmware and
take control of the system very early in the resume process, without
disturbing the contents of the main memory.

Since the attacker has code execution before any protections are in place,
they are able to walk through all of memory
to look for secrets or disable any OS-level protections like screen lock processes.
This risk is especially
dangerous since the LUKS and BitLocker disk encryption keys are typically stored in RAM while
the computer is asleep, allowing the attacker to gain access to the decrypted
disks without requiring any user passwords.

Additionally, System Management Mode (SMM) memory (SMRAM)
is not normally modified during the resume path. Normally all of the
SMM modules are installed during the cold boot and then the SMRAM
is locked so that it can not be modified by the OS. On a resume,
the SMRAM is unlocked, so the firmware normally leaves all of the
current SMM modules in place and locks the SMRAM as-is.
Since the attacker has access with the SMRAM unlocked, it can gain
temporary persistence by writing
malicious code into SMRAM, and then locking it, which would provide a
nearly undetectable backdoor until the next hard reboot.

Attack scenarios

Since CVE-2020-8075 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 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 cold boot and validation is easily distinguished
from a warm boot by the FPGA, 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.

Previous attacks

CVE-2020-8705 is not the first time there have been security vulnerabilities
in the wake-from-sleep boot path, nor the first TOCTOU against firmware.
Since S3 sleep is essentially a cold
reboot for the CPU, there are many internal states that need to be restored.
Much of the platform security depends on one-time writable lock registers,
and there have been multiple vulnerabilities that caused by race conditions
in setting them, or in some cases where the vendors forgot to re-enable
the protection when resuming from sleep.

S3 sleep attacks

Some examples of prior sleep attacks are the
Snorlax (VU#577140)
vulnerability found by Cornwell, Butterworth, Kovah, and Kallenberg,
in which the BIOS Lock Enable (BLE) bit in the BIOS_CNTL register is
reset to its default value after a system reset. If the BIOS does not
set it again after waking from sleep, then any code running in ring 0
would be able to overwrite the system firmware.

Vilaça discovered and disclosed the similar
Prince Harming
vulnerability. He found that Apple did not set the Flash Lock Down
(FLOCKDN) and the Protected Range Registers (PRR) when resuming
from sleep on some platforms, which left the SPI flash writable to any
ring 0 code or process that could access physical memory.

Wojtczuk and Kallenberg found Darth Venamis (VU#976132),
which allowed an attacker to modify the S3 resume script on some platforms
to gain code execution in the resume path prior to the FLOCKDN, BIOS_CNTL
or other platform bits being reset, giving the attacker write access to
the firmware flash during the resume.

Kovah and I ported the Darth Venamis attack to the MacBooks
as part of Thunderstrike 2, showing that these
vulnerabilities were portable across operating systems and firmware
implementations. Darth Venamis and Thunderstrike 2 were largely fixed by
storing the S3 resume script in SMRAM, the “S3 Lockbox”, so that it is
not accessible to normal processes after the firmware has finished.

Other researchers have found that some OEMs are skipping validation during
S3 resume in the later steps as well. Alexander Ermolov found that Dell performed Bootguard validation in the DXE phase, which was trivially bypassable by
removing the BootGuardDxe module. He also observed in his S3 microcode downgrade talk
that the “ACM does not verify BIOS when waking from S3 (performance optimizations) except each 12 boot“, which is the same root cause as CVE-2020-8705.

Matrosov hinted that “S3 rootkits coming :)”,
and disclosed some vendors that were not properly protecting the S3 resume
path on their platform, allowing Bootguard to be bypassed.

Sleep attacks on other devices

Other hardware has suffered from this sort of sleep attack as well.
Han’s “Bad Dream” TPM attacks (CVE-2018-6622)
provide malicious data to the TPM on resume, allowing an attacker to subvert
the measured boot on TPM sealed data. Since the TPM does not maintain
state during sleep, it trusted that the CPU was providing the correct
blob for the PCRs upon resume.

TOCTOU on firmware

In 2019, Bosch and I discovered that there were TOCTOU attacks possible
against Bootguard (on normal boots) due to cache flushes causing some
instructions to be re-read from the SPI flash after the ACM had validated
the signature on the PEI region.
This vulnerability was assigned CVE-2019-11098 was
only recently patched
due to the difficulty in fixing the entire class of XIP bugs.

Bootguard background

Modern Intel x86 CPUs no longer boot by a simple jump to the legacy
reset vector at 0xF00:FFF0 in real mode. Unfortunately the details are
not public for some reason, so security researchers have had to reverse
engineer the behaviour from observing the devices. This is a summary of
my observations as well as detailed descriptions by
Matrosov
and Ermolov.

The CPU’s on-die boot ROM first reads
the Firmware Interface Table (FIT) at 0xFFFFFFC0 in the memory
mapped flash and installs any appropriate microcode updates listed in
the FIT.
The CPU then locates the Intel signed Authenticated Code Module (ACM)
entry in the FIT and copies the ACM into cache. Intel’s signature
on the ACM is validated by the CPU before jumping to the ACM’s entry point.

The ACM receives Bootguard configuration from the Intel Management Engine
(ME) (which has it’s own chain-of-trust and hardware boot ROM).
This configuration includes the hash of the OEM public key and
the configuration registers, and is stored in one-time-programmable
(OTP) fuses. These fuse values are “blown” by the OEM at the end of
manufacturing and are permanent — they can not be changed after the
configuration is programmed.

On a cold boot, the ACM locates the Bootguard Key Manifest (KEYM)
and copies it into cache, then validates the OEM signature on it,
ensuring that it was signed with the public key that matches the hash
from the OTP fuses. The key in the key manifest is used to sign the
Bootguard Policy Manifest (ACBP), which is also copied into cache
and the signature validated.

One section of the ACBP is the Initial Bootblock Element (IBBS), which
has the list of Initial Boot Block (IBB) segments that are protected
by Bootguard. These typically include the UEFI PEI and sometimes the
DXE firmware volumes, although not the NVRAM regions. The ACM copies
all of the segments of the IBB from the flash into cache and computes
the hash of it, which is then compared to the hash stored in the signed
IBBS.

Since this chain of signatures and hashes goes all the way to an on-die
boot ROM with a permanent public key, Bootguard is said to be a hardware
root of trust.
Bootguard allows the CPU manufacturer to verify the ACM, which verifies
the OEM’s firmware and transfers the chain to the OEM’s IBB.
The OEM is then responsible for verifying the rest of its firmware,
which then verifies the bootloader signature, which then verifies the
OS kernel signature, and so on.
This is a significant improvement over OS level security,
which assumes that the bootloader is valid, or UEFI SecureBoot,
which validates the bootloader, but assumes that the firmware is unmodified.

If any of the KEYM or ACBP signature checks fail, or if the IBB
hash comparison fails, then the ACM takes action depending on the
Bootguard OTP configuration.
These Bootguard configurations available have not publicly disclosed
by Intel, although the FIT tool has several profiles that can be
selected related to the security configuration and
some researchers have tried to reverse engineer it:

typedef struct BG_PROFILE
{
    unsigned long Force_Boot_Guard_ACM : 1;
    unsigned long Protect_BIOS_Environment : 1;
    unsigned long CPU_Debugging : 1;
    unsigned long BSP_Initialization : 1;
    unsigned long Measured_Boot : 1;
    unsigned long Verified_Boot : 1;
    unsigned long Key_Manifest_ID : 4;
    // 00b – do nothing
    // 01b – shutdown timeout
    // 11b – immediate shutdown
    unsigned long Enforcement Policy : 2;
    unsigned long : 20;
};

Many OEMs seem to select the “immediate shutdown” option, although
there some choose “do nothing” and push validation elsewhere,
which can lead to its own set of vulnerabilities.

During a S3 resume, the CPU starts up in the same way. The ACM is copied
from flash into cache and validated by the CPU hardware, then the ACM
checks to see if the system is in a cold boot or a resume. If it is a
resume, the OTP configuration can select to either quickly jump into the
resume path or to re-validate the IBB.

Root cause

Bootguard Profile in the FIT tool

The root cause of CVE-2020-8705 is that most OEM’s select the Bootguard
configuration in the Intel ME’s OTP fuses
to validate the hashes of the firmware flash only on a cold boot.
Since this is the configured behavior, Intel initially dismissed the
vulnerability as “functioning as designed” and closed the issue:

After review we have determined that Boot Guard is functioning as designed.
Configuring Boot Guard to check every S3 resume is an available option to OEMs.

The OEMs selected the fast-resume option in the OTP fuses so that the
wake-from-sleep is as fast as possible to meet Microsoft’s logo
requirements
:

The S3 resume logo test uses the PwrTest tool to cycle the system through
four ACPI S3 sleep transitions. The total resume time of each sleep
transition is measured. The total resume time is validated to be less
than 2000 milliseconds for each of the last three sleep transitions. Total
resume time is measured as the sum of the BIOS Initialization and Driver
Initialization phase durations.

The assumption is that the flash was checked during the initial boot,
so that it is not necessary to check it during resume since it is a “ROM”.
This is a classic Time-of-check / Time-of-Use (TOCTOU) error, since
the SPI flash is not read-only and can be altered after the initial boot.
When the OEMs made the choice for faster boot there were not easy tools
for TOCTOU against SPI flash, so it might not have seemed as important.
Unfortunately the choices they made were burned in the OTP fuses, so it
is not possible for them to now retroactively patch the systems without
desoldering and replacing the PCH.

Additionally, Bootguard does recheck the flash every X resumes (12?),
however the access pattern is different from a normal resume which makes
it possible for a flash emulator to distinguish between the two resume paths.

There is a secondary vulnerability in that even if the firmware flash were
validated, the Memory Type Range Registers (MTRR) that control the caches
were not being correctly setup in the ACM, allowing an Execute-in-Place (XIP)
attack against the resume process if the attacker had a TOCTOU capable
flash emulator.

Mitigation

After initially dismissing it as not a bug, Intel reopened the original issue,
possibly after pressure from OEMs. The biggest
problem for the OEMs is that this Bootguard configuration is stored
in OTP fuses in the Platform Controller Hub (PCH), which can only
be written once and which are permanently programmed when the device
exits manufacturing mode. OEMs that wanted to retroactively secure
the millions of devices already in the field are not able to do so,
since the OTP can not be changed.

As a result, Intel has built a new CSME firmware as part of INTEL-SA-00391.
They don’t disclose how they have fixed CVE-2020-8705 (along with a dozen others),
although my assumption is that it does not send the
actual fuses to the ACM, but instead tells it to always check the IBB
in the flash. This patch allows the OEMs to update their devices without
requiring hardware modifications, so it should improve the security
of sleeping systems.

This workaround also points to a weakness in the OTP
fuses – access to them is through the software running on the ME, so
the x86 can not trust that they are receiving the actual one-time-programmed
values. A code execution attack against the ME, such as
Mark Ermolov’s DMA attack against the CSME
or Intel SA-00086,
allow arbitrary a bypass of Bootguard configuration.

Proof of concept

The CVE-2020-8705 vulnerability was detected and the proof of concept was
demonstrated using the spispy open source SPI flash emulator,
an open source hardware board with an ECP5 FPGA and 32MB DRAM that
pretends to be a SPI flash.

The spispy can operate in a passive
monitoring mode, which logs the addresses being accessed by the CPU,
and these logs can be analyzed to find repeated reads. The spispy can
also operate in an TOCTOU mode that allows it to replace the data being
read at certain addresses based on the access patterns. It also has a
full emulation mode that replaces all of the flash, which is useful for
developing or testing new firmware since the DRAM can be updated much
faster than the SPI NOR flash chips.

The vulnerability was detected in several systems as part of continuing
research into firmware TOCTOU attacks, similar to the work
with Peter Bosch on CVE-2019-11098.
Tested systems included a Intel NUC 8 and
a Lenovo Thinkpad X1 and T490, although it is likely to affect nearly
all commodity systems with Intel CPUs.

Timeline

  • 2020-01-24: Bootguard S3 resume vulnerability reported to Intel
  • 2020-01-25: Intel responds that they are looking into it
  • 2020-01-27: XIP in resume path reported to Intel
  • 2020-01-27: Cache flush in resume path reported to Intel
  • 2020-02-05: Intel responds that the XIP and cache issues are AMI’s responsibility
  • 2020-02-18: Intel closes Bootguard issue with “functioning as designed
  • 2020-03-03: Issue disclosed to OEMs since Intel did not consider it a bug
  • 2020-04-07: Intel re-opens Bootguard issue (influenced by OEMs?)
  • 2020-06-01: Intel sends updated ME firmware with fix in place for testing
  • 2020-xx-xx: Intel agrees on November publication date
  • 2020-11-10: Public disclosure and publication

2020
Security


Last update: November 10, 2020



Source link

Is your business effected by Cyber Crime?

If a cyber crime or cyber attack happens to you, you need to respond quickly. Cyber crime in its several formats such as online identity theft, financial fraud, stalking, bullying, hacking, e-mail fraud, email spoofing, invoice fraud, email scams, banking scam, CEO fraud. Cyber fraud can lead to major disruption and financial disasters. Contact Digitpol’s hotlines or respond to us online.

Digitpol’s Cyber Crime Investigation Unit provides investigative support to victims of cyber crimes. Digitpol is available 24/7. https://digitpol.com/cybercrime-investigation/

Europe +31558448040
UK +44 20 8089 9944
ASIA +85239733884