0 %

When “secure” isn’t secure at all: High‑impact UEFI vulnerabilities discovered in Lenovo consumer laptops

April 19, 2022

ESET researchers uncover a number of vulnerabilities in varied Lenovo laptop computer fashions that permit an attacker with admin privileges to reveal the person to firmware-level malware

ESET researchers have found and analyzed three vulnerabilities affecting varied Lenovo client laptop computer fashions. The primary two of those vulnerabilities – CVE-2021-3971, CVE-2021-3972 – have an effect on UEFI firmware drivers initially meant for use solely in the course of the manufacturing strategy of Lenovo client notebooks. Sadly, they had been mistakenly included additionally within the manufacturing BIOS photos with out being correctly deactivated. These affected firmware drivers will be activated by attacker to immediately disable SPI flash protections (BIOS Management Register bits and Protected Vary registers) or the UEFI Safe Boot characteristic from a privileged user-mode course of throughout OS runtime. It implies that exploitation of those vulnerabilities would permit attackers to deploy and efficiently execute SPI flash or ESP implants, like LoJax or our newest UEFI malware discovery ESPecter, on the affected units.

To know how we had been capable of finding these vulnerabilities, take into account the firmware drivers affected by CVE‑2021-3971. These drivers instantly caught our consideration by their very unlucky (however surprisingly trustworthy) names: SecureBackDoor and SecureBackDoorPeim. After some preliminary evaluation, we found different Lenovo drivers sharing a couple of widespread traits with the SecureBackDoor* drivers: ChgBootDxeHook and ChgBootSmm. Because it turned out, their performance was much more attention-grabbing and could possibly be abused to disable UEFI Safe Boot (CVE-2021-3972).

As well as, whereas investigating above talked about weak drivers, we found the third vulnerability: SMM reminiscence corruption contained in the SW SMI handler perform (CVE-2021-3970). This vulnerability permits arbitrary learn/write from/into SMRAM, which may result in the execution of malicious code with SMM privileges and doubtlessly result in the deployment of an SPI flash implant.

We reported all found vulnerabilities to Lenovo on October 11th, 2021. Altogether, the record of affected units accommodates a couple of hundred completely different client laptop computer fashions with tens of millions of customers worldwide, from inexpensive fashions like Ideapad-3 to extra superior ones like Legion 5 Professional-16ACH6 H or Yoga Slim 9-14ITL05. The total record of affected fashions with lively growth help is revealed within the Lenovo Advisory.

Along with the fashions listed within the advisory, a number of different units we reported to Lenovo are additionally affected, however gained’t be mounted resulting from them reaching Finish Of Improvement Help (EODS). This contains units the place we noticed reported vulnerabilities for the primary time: Ideapad 330-15IGM and Ideapad 110-15IGR. The record of such EODS units that we’ve got been in a position to establish will probably be accessible in ESET’s vulnerability disclosures repository.

Lenovo confirmed the vulnerabilities on November 17th, 2021, and assigned them the next CVEs:

Vulnerability disclosure timeline:

  • 2021-10-11: Vulnerabilities reported to Lenovo
  • 2021-10-12: Lenovo responded and confirmed it was investigating the problems
  • 2021-11-17: Lenovo confirmed the vulnerabilities and knowledgeable us of the deliberate advisory publication date – February 8th, 2022
  • 2022-01-20: Lenovo requested to postpone public disclosure to the brand new date – April 18th – resulting from encountering growth points
  • 2022-04-18: Lenovo safety advisory revealed
  • 2022-04-19: ESET Analysis blogpost revealed

UEFI firmware theoretical fundamentals

Earlier than we begin with the evaluation of the reported vulnerabilities, we wish to present an introduction to the essential principle of UEFI protocols, System Administration Mode, UEFI NVRAM variables, UEFI Safe Boot, and fundamental SPI flash write safety.

Notice that our purpose is to elucidate solely the mandatory minimal required for an understanding of the evaluation of the vulnerabilities reported right here. For many who are already acquainted with these matters, we propose leaping on to the Technical evaluation part. For many who take into account this introduction inadequate, we extremely advocate wanting into the series of blogposts written by researchers from SentinelOne and the UEFI Specification.

UEFI providers and protocols

UEFI defines two varieties of providers for use by UEFI drivers and functions – Boot (EFI_BOOT_SERVICES) and Runtime (EFI_RUNTIME_SERVICES) providers. Each are handed to the driving force’s or software’s entry level by way of the EFI_SYSTEM_TABLE argument.

They supply the essential capabilities and information constructions crucial for the drivers and functions to do their job, reminiscent of putting in protocols, finding present protocols, reminiscence allocation, UEFI variable manipulation, and so forth.

UEFI boot drivers and functions use protocols extensively. Within the context of UEFI, protocols are merely teams of capabilities recognized by a GUID. These protocols, as soon as put in, reside in reminiscence and can be utilized by different drivers or functions, till EFI_BOOT_SERVICES.ExitBootServices is named. The UEFI specification defines many such protocols to cowl the most typical firmware use-case situations, however firmware builders are nonetheless in a position to outline their very own protocols to increase this fundamental performance.

UEFI variables

UEFI variables are a particular firmware storage mechanism utilized by UEFI modules to retailer varied configuration information, together with boot configuration, UEFI Safe Boot settings, certificates, and comparable information. These variables are at all times recognized by a variable title and a namespace (GUID).

When making a UEFI variable, attributes are used to point how the variable ought to be saved and maintained by the system – this manner one could make variables persistent (surviving energy cycles), momentary, and even authenticated. Authenticated within the context of the NVRAM variables implies that the variable content material will be modified provided that the brand new variable information is accurately signed by the approved non-public key – learn entry to the variable is allowed to anybody.

Examples of a few of these attributes comply with; right here we record solely crucial ones:

    Variables utilizing this attribute persist throughout the ability cycles and are saved in mounted {hardware} storage (NVRAM) with restricted capability (usually round 64MB).
    If the BS attribute is about, variables with out the RT attribute set won’t be seen to the GetVariable perform after the execution of EFI_BOOT_SERVICES.ExitBootServices.
    To entry a variable by way of the GetVariable perform after the execution of EFI_BOOT_SERVICES.ExitBootServices, the RT attribute should be set.

A full record of attributes and their utilization guidelines will be discovered within the UEFI specification.

It’s necessary to notice that since Home windows 8 an API permits entry to UEFI variables from a privileged userland course of (administrator with SE_SYSTEM_ENVIRONMENT_NAME privilege).These API capabilities are:

System Administration Mode (SMM)

SMM is a extremely privileged execution mode of x86 processors, also known as “ring ‑2”.

SMM code is written inside the context of the system firmware and is often used for varied duties together with superior energy administration, execution of OEM proprietary code, and safe firmware updates. It gives an impartial execution surroundings fully invisible to the operating working system, and the code and information utilized in SMM are saved in hardware-protected reminiscence – accessible solely from SMM – referred to as SMRAM.

To enter SMM, a particular processor interrupt referred to as SMI (System Administration Interrupt) must be triggered. SMIs will be triggered by way of software program means or by the platform {hardware}. For the needs of this blogpost, it’s ample to grasp that one of many methods to generate an SMI (particularly a software program SMI – SW SMI) and enter SMM on Intel structure methods is to write down to I/O port 0xB2 (utilizing the OUT instruction). That is usually utilized by software program to invoke firmware providers throughout system runtime.

Defining SW SMI handlers within the UEFI firmware

To know what occurs underneath the hood once we use the above-mentioned technique of triggering an SW SMI, we have to look into quantity 4 of the UEFI Platform Initialization Specification, Version 1.4 (ZIP archive), and discover the definition of the EFI_SMM_SW_DISPATCH2_PROTOCOL (proven in Determine 1).

Determine 1. EFI_SMM_SW_DISPATCH2_PROTOCOL definition

As written within the specification, this protocol can be utilized by SMM modules to put in handler capabilities that may reply to particular software program interrupts.

To put in such a handler perform, the EFI_SMM_SW_DISPATCH2_PROTOCOL.Register service perform is used; the perform kind definition is proven in Determine 2.

Determine 2. EFI_SMM_SW_DISPATCH2_PROTOCOL.Register perform definition

This service installs a DispatchFunction perform that will probably be referred to as when the software program SMI supply specified by RegisterContext‑>SwSmiInputValue is detected. In different phrases, this DispatchFunction will probably be referred to as once we generate an SW SMI interrupt by writing the identical SwSmiInputValue as was specified within the RegisterContext‑>SwSmiInputValue throughout handler set up, to the I/O port 0xB2.

For the SW SMI interrupts, parameters are most frequently handed to the SMI handler utilizing CPU registers. When the SW SMI interrupt is triggered, the context for the entire CPUs on the time of triggering the interrupt is saved to the SMRAM. The invoked SMI handler can simply learn and modify this context utilizing the EFI_SMM_CPU_PROTOCOL capabilities ReadSaveState and WriteSaveState, respectively.

Major SPI flash safety mechanisms

UEFI firmware often resides within the embedded flash reminiscence chip positioned on the pc’s motherboard (SPI flash chip). It’s non-volatile reminiscence and it’s linked to the processor by way of the Serial Peripheral Interface (SPI).

This reminiscence shouldn’t be affected by working system reinstallation and due to this fact presents a tempting goal for risk actors deploying their implants – as was the case of LoJax, MosaicRegressor, and MoonBounce.

A number of safety mechanisms can be found for the prevention of undesirable modifications of the SPI flash and the first line of protection is offered by the particular memory-mapped configuration registers uncovered by the chipset itself – the BIOS Management Register and 5 Protected Vary registers.

BIOS Management Register

On this register, three particular bits are used for SPI flash entry management. Notice that though they might be named in another way on different chipsets, the precept is identical.

  1. BIOSWE (bit 0)

When set, entry to the BIOS house is enabled for each learn and write cycles, in any other case entry is learn solely.

  1. BLE (bit 1)

When set, BIOSWE could possibly be set from 0 to 1 solely by SMM code. Any try to set BIOSWE from non-SMM code will set off SMI. This gives a chance for the OEM to implement an SMI handler to guard the BIOSWE bit by setting it again to 0.

  1. SMM_BWP (bit 5)

When set, the BIOS area shouldn’t be writable except all processors are in SMM and BIOSWE is 1. Setting this bit resolves the Speed Racer race situation vulnerability (an exploit for this vulnerability was current within the ReWriter_binary software, which was utilized by the Sednit group to deploy LoJax).

Protected Vary registers (PR0-PR4)

Every register specifies impartial learn/write permissions for a particular vary of SPI Flash BIOS area reminiscence. They are often set provided that the Flash Configuration Lock-Down (FLOCKDN) bit in {Hardware} Sequencing Flash Standing (HSFS) register shouldn’t be set.

This FLOCKDN bit ought to be set by the platform firmware throughout platform initialization – proper after setting the Protected Vary (PR) registers. As soon as FLOCKDN is about, it’s cleared solely after the subsequent {hardware} reset. It implies that reminiscence ranges protected by Protected Vary registers can’t be modified by any runtime code (together with SMM code) after they’re locked. Even reliable firmware updates should be carried out earlier than PR registers are locked.

Options accessible on present methods

Fashionable methods these days often include options offering hardware-based boot integrity (reminiscent of Intel Boot Guard) which, if configured correctly and with out further vulnerabilities, protects from booting untrusted firmware code even when the above-mentioned chipset-provided protections fail to guard the SPI flash resulting from misconfiguration or vulnerability.

Methods to entry PCI/PCIe configuration house

The BIOS Management Register, Safety Vary registers, and plenty of different configuration registers will be learn or written by accessing the PCI(e) configuration house. The placement (or tackle) of the PCI(e) configuration house for the precise PCI-compatible units (e.g., SPI flash) is specified by the three values:

Configurations associated to this system are positioned on the offsets inside this configuration house. There are two widespread methods to entry the PCI(e) configuration house:

On this case, machine I/O directions IN and OUT together with 0xCF8 (CONFIG_ADDRESS) and 0xCFC (CONFIG_DATA) I/O ports are used to entry particular configuration information in PCI configuration house. As it’s not crucial for the aim of our blogpost, we won’t be diving into the small print right here.

  • Utilizing Reminiscence Mapped I/O (MMIO)

When utilizing Reminiscence-Mapped I/O, the PCI configuration house is mapped on to most important reminiscence tackle house; due to this fact, the configuration information will be accessed virtually the identical means as another information. All that must be recognized is the PCI tackle of the specified information, so the place can we discover this tackle? We will assemble it on our personal if we all know:

  1. the MMIO base tackle (will be discovered inside MCFG ACPI desk)
  2. Bus, Gadget, Perform, and Offset (additionally known as Register) values figuring out the info that we need to entry (you’ll find them in a chipset’s datasheet).

An instance of the macro encoding these values into PCI tackle will be present in EDK2’s PciLib.h header file. Alternatively, a Python implementation of the capabilities translating MMIO PCI tackle to particular person identifiers and vice versa is proven in Determine 3.

Determine 3. PCI tackle encoding/decoding in Python

UEFI Safe Boot

UEFI Safe Boot is outlined within the UEFI specification, and its most important objective is to confirm the integrity of the boot elements to make sure that solely elements trusted by the platform are allowed to be executed. What elements will probably be included on this verification course of will depend on the UEFI Safe Boot coverage implementation within the particular platform – most often, solely third-party UEFI drivers, functions and OPROMs are being verified, and the drivers on the SPI flash are implicitly thought-about trusted.

To determine what’s trusted and what’s not, UEFI Safe Boot makes use of particular databases saved within the authenticated NVRAM variables, particularly db and dbx.

  • The db database accommodates an inventory of trusted public key certificates which might be approved to authenticate boot element signatures or, along with the certificates, it might additionally comprise an inventory of hashes of the elements which might be allowed to be executed whether or not or not they’re signed.
  • The dbx database accommodates public key certificates or hashes of UEFI executables which might be not allowed to be executed – to stop execution of signed executables with recognized vulnerabilities, revoked certificates, and so forth.

Technical evaluation

We begin with our evaluation of the Lenovo drivers affected by CVE-2021-3971 and CVE-2021-3972, after which proceed with the SMM vulnerability CVE-2021-3970.

At the start of our blogpost, we talked about that the SecureBackDoor* and ChgBoot* drivers share some widespread traits, so what’s the connection between them? Each use the UEFI variables inside the 6ACCE65D-DA35-4B39-B64B-5ED927A7DC7E namespace as a management mechanism for deciding whether or not to activate their performance (we’ll consult with this GUID as LENOVO_BACKDOOR_NAMESPACE_GUID).

CVE-2021-3971 – SecureBackDoor driver – disable SPI flash protections

We are going to begin with the evaluation of the CVE-2021-3971 vulnerability, which permits an attacker to disable SPI flash write-protections mechanisms by merely creating the NVRAM variable. When platform firmware detects this NVRAM variable throughout bootup, it skips execution of the code liable for the establishing BIOS Management Register and Protected Vary register-based SPI flash protections.

Because of this, the exploited system will permit modification of the SPI flash even when carried out from non-SMM code and thus permit an attacker to deploy malicious code on to the firmware storage.

This “Disable SPI flash protections characteristic” is applied by the next drivers within the firmware of affected laptops:

  • SecureBackDoorPeim (16F41157-1DE8-484E-B316-DDB77CB4080C)
  • SecureBackDoor (32F16D8C-C094-4102-BD6C-1E533F8810F4)

To disable or deactivate the above-mentioned SPI flash protections by exploiting this vulnerability, the person solely must create an NVRAM variable with:

  • Identify: cE!
  • Attributes: NV + BS + RT (0x00000007)
  • Worth: Any non-null byte

after which restart the affected system.

To know how simple that is, Home windows customers can disable these protections by exploiting the CVE-2021-3971 vulnerability immediately from the privileged userland course of (administrator with SE_SYSTEM_ENVIRONMENT_NAME privilege) utilizing the Home windows API perform SetFirmwareEnvironmentVariable.

In our evaluation, we’ll work with the firmware picture (model 1GCN25WW) of the Lenovo 110-15IBR, which is among the units affected by the CVE-2021-3971 vulnerability.

SecureBackDoorPeim evaluation

To return to a little bit of principle, the UEFI boot sequence consists of assorted phases and one of many earliest is named the Pre-EFI Initialization (PEI) part. Throughout this part, Pre-EFI Initialization Modules (PEIMs) are executed to carry out varied duties together with initialization of everlasting reminiscence and invocation of the subsequent boot part – Driver Execution Setting (DXE). To cross info from the PEI part to the DXE part, particular information constructions referred to as Hand-Off Blocks (HOBs) are used.

SecureBackDoorPeim is a PEI module liable for each studying the content material of the UEFI variable cE!, which belongs to the namespace LENOVO_BACKDOOR_NAMESPACE_GUID, and getting ready the right HOB information construction to cross its worth to the SecureBackDoor DXE part driver.

It does so in three easy steps, as proven in Determine 4.

Determine 4. Hex-Rays-decompiled code of SecureBackDoorPeim module

  1. Use EFI_PEI_READ_ONLY_VARIABLE2_PPI.GetVariable perform with the VariableName and VariableGuid parameters set to values cE! and LENOVO_BACKDOOR_NAMESPACE_GUID respectively.
  2. To cross this info to the SecureBackDoor DXE driver, create a HOB information construction recognized by the next GUID AD7934E7-D800-4305-BF6F-49ED9918E1AB. To make issues less complicated, let’s title this HOB information construction GUID SECURE_BACKDOOR_HOB_GUID.
  3. Lastly, it saves the worth retrieved from the cE! variable to offset 0x18 of the newly created HOB.

SecureBackDoor evaluation

SecureBackDoor is a DXE driver liable for deactivating SPI flash protections if it finds a HOB recognized by SECURE_BACKDOOR_HOB_GUID within the HOB record. In Determine 5 we are able to see that to search out this HOB, it walks by means of the record of HOBs, and appears for the one created beforehand by the SecureBackDoorPeim module by matching it with the SECURE_BACKDOOR_HOB_GUID.

Determine 5. Hex-Rays-decompiled SecureBackDoor code liable for discovering HOB created by SecureBackdoorPeim

If this HOB is discovered, the driving force will get the byte worth at offset 0x18 – which is the worth beforehand retrieved from the cE! UEFI variable by SecureBackDoorPeim – and if this worth is completely different from 0x00, it registers the DXE_PCH_PLATFORM_POLICY_PROTOCOL protocol notify perform that zeroes the BiosLock bit contained in the DXE_PCH_PLATFORM_POLICY_PROTOCOL.LockDownConfig bitmask (for associated kind definitions, see TianoCore’s PchPlatformPolicy.h header file at GitHub).

To know the way it really disables SPI flash protections, we have to look into two completely different firmware drivers:

  • PchBiosWriteProtect (B8B8B609-0B6C-4B8C-A731-DE03A6C3F3DC)
  • BiosRegionLock (77892615-7C7A-4AEF-A320-2A0C15C44B95)

PchBiosWriteProtect evaluation

PchBiosWriteProtect is a SMM module. In Determine 6 we are able to see that it checks whether or not the BiosLock bit inside DXE_PCH_PLATFORM_POLICY_PROTOCOL.LockDownConfig (kind PCH_LOCK_DOWN_CONFIG) is about, by performing a bitwise AND operation with worth 0x08 (which is 0b1000 in binary illustration).

Determine 6. Hex-Rays-decompiled code from PchBiosWriteProtect liable for initialization of BIOS Management Register – associated SPI flash protections

If it’s not set, it skips a couple of traces of code which might be liable for:

  • Performing MMIO learn operation (line 15 in Determine 6) by studying a 32-bit worth from the tackle 0xE00F8054. If we cross this tackle as an argument to the Python perform pci_decode_from_addr, which we launched within the Determine 3: that perform will print the tackle, decoded as Bus: 0, Gadget: 0x1F, Perform: 0, Offset: 0x54.
    Based mostly on these values and understanding that the affected laptop computer (in our case Lenovo 110-15IBR) makes use of the N-series Intel System-on-a-Chip (SoC), we are able to discover in its datasheet (part 33.14.13, web page 2258) that it’s accessing the SPI Base tackle (SBASE), 32-bit PCI configuration register containing the tackle of the SPI configuration house (we’ll name it SPIBAR), and saves it into the worldwide variable.
  • Registering the SW SMI handler perform DispatchFunction (line 22 in Determine 6)
    This registered SW SMI handler DispatchFunction is invoked throughout platform initialization and if we glance into the code of this perform in Determine 7 beneath, we see that it’s liable for setting bit 5 contained in the register positioned at SPIBAR offset 0xFC. If we glance into the documentation (part 10.48 BCR), we are able to see that this corresponds to SMM_BWP (or EISS for our chipset) little bit of the BIOS Management Register.

Determine 7. Hex-Rays-decompiled code of DispatchFunction from PchBiosWriteProtect

In the long run, DispatchFunction can be liable for registering SMI handler perform (ClearBIOSWE in Determine 7) dealing with the SMI interrupt, which is triggered when somebody tries to set the BIOSWE bit contained in the BIOS Management Register from non-SMM code whereas the BIOS Management Register BLE bit is about. In that case, the put in handler will set BIOSWE (or WPD for our chipset) bit again to 0.

Because of this, skipping this code will end in misconfiguration of the BIOS Management Registers, exposing the system to the chance of SPI flash modification.

BiosRegionLock evaluation

The second driver, BiosRegionLock, is liable for establishing Protected Vary registers PR0-PR4. Much like the PchBiosWriteProtect described above, it makes use of the BiosLock bit inside DXE_PCH_PLATFORM_POLICY_PROTOCOL.LockDownConfig (kind PCH_LOCK_DOWN_CONFIG) to determine whether or not or to not set SPI flash protections – on this case Protected Vary registers.

As proven in Determine 8, if it finds out that the BiosLock bit shouldn’t be set, it’s going to merely skip code liable for setting these registers and thus depart SPI flash unprotected.

Determine 8. Hex-Rays-decompiled code liable for setting the Protected Vary registers

CVE-2021-3972 – ChgBootDxeHook driver – disable UEFI Safe Boot

The subsequent vulnerability we’ll check out is the CVE-2021-3972. This vulnerability permits an attacker with elevated privileges to alter varied UEFI firmware settings, together with the UEFI Safe Boot state, or for instance restoring the UEFI firmware manufacturing unit settings, all by merely creating one UEFI variable.

For sure, such an motion would have severe affect on system safety. Disabling UEFI Safe Boot would imply that the firmware gained’t implement integrity verification of the UEFI drivers and functions in the course of the boot course of and can thus permit loading of any untrusted or malicious ones. However, restoring manufacturing unit settings wouldn’t immediately disable UEFI Safe Boot, however may expose a system to the chance of deploying some UEFI functions, reminiscent of bootloaders, with recognized vulnerabilities (e.g. see BootHole), thus permitting a bypass of UEFI Safe Boot.

In our evaluation, we’ll work with the firmware picture (model 7XCN41WW) of the Lenovo 330-15IGM, which is affected by the CVE-2021-3972 vulnerability.

For instance, to disable UEFI Safe Boot on Lenovo 330-15IGM, the person want solely create a UEFI variable with:

  • Identify: ChgBootSecureBootDisable or ChgBootChangeLegacy
  • Attributes: NV + BS + RT (0x00000007)
  • Worth: Any non-null byte

and restart the laptop computer.

As an example how simple it’s, Home windows customers can create these variables from the privileged userland course of (administrator with SE_SYSTEM_ENVIRONMENT_NAME privilege) utilizing the Home windows API perform SetFirmwareEnvironmentVariable.

This backdoor “characteristic” is applied by the next two drivers within the firmware of affected units:

  • ChgBootSmm (4CA0062A-66FE-4BE7-ACE6-FDE992C1C5EC)
  • ChgBootDxeHook (C9C3D147-9A92-4D00-B3AE-970E58B5C3AC)

ChgBootSmm evaluation

ChgBootSmm is an SMM module liable for registration of the SW SMI handler perform. As proven in Determine 9, it registers this SMI handler utilizing the EFI_SMM_SW_DISPATCH2_PROTOCOL.Register perform and units the SwSmiInputValue to 0xCA. Because of this one can set off execution of this perform by writing the worth 0xCA to I/O port 0xB2.

Determine 9. Hex-Rays-decompiled codeChgBootSmm registers SW SMI handler quantity 0xCA

By wanting into this put in SMI handler in Determine 10, we are able to see that it makes use of EFI_SMM_VARIABLE_PROTOCOL capabilities SmmGetVariable and SmmSetVariable to learn from and write into varied UEFI variables and the choice of what variable will probably be created or modified is made based mostly on the worth from RBX register saved state.

Determine 10. Hex-Rays-decompiled code of SW SMI handler put in by the ChgBootSmm driver

Furthermore, every written variable has the identical attributes bitmask – 0x00000007 (NV|BS|RT) – that means that the entire variables created will probably be saved in non-volatile storage and thus survive an influence cycle.

The total record of the variables that may be accessed utilizing this SW SMI handler are:

    • ChgBootSecureBootDisable
    • ChgBootSetPxeToFirst
    • ChgBootSetEfiPxeOneTime
    • ChgBootRestoreFactory
    • ChgBootFullRese
    • ChgBootSecureBootEnable
    • ChgBootBootOrderSetDefault
    • ChgBootChangeLegacy
    • ChgBootLegacyLoadDefault
    • ChgBootUefiLoadDefault
    • @Rm
    • OneTimeDisableFastBoot
  • Namespace: A04A27F4-DF00-4D42-B552-39511302113D

Discover the variables beginning with the ChgBoot string: these variables are used as “instructions” for the ChgBootDxeHook DXE driver, indicating whether or not to carry out some motion or not. Generally their names are fairly self-explanatory and from the safety standpoint, the next are probably the most attention-grabbing:

  • ChgBootSecureBootDisable and ChgBootChangeLegacy
    If created (any of them), ChgBootDxeHook disables the UEFI Safe Boot characteristic in the course of the subsequent boot.
  • ChgBootRestoreFactory
    If created, ChgBootDxeHook restores manufacturing unit default values for UEFI Safe Boot variables PK, KEK, db, and dbx in the course of the subsequent boot. This would possibly trigger a number of issues, from corrupting the customized Safe Boot keys utilized by the sufferer and thus stopping booting the system, to loading the dbx, which could not comprise the newest revocation information. The latter may expose the system to the chance of deploying some UEFI functions, reminiscent of bootloaders, with recognized vulnerabilities (e.g. BootHole) and thus permitting an attacker to bypass UEFI Safe Boot verification too.

All the above-mentioned ChgBoot* UEFI variables will be created even with out the assistance of this SW SMI handler – for instance utilizing Home windows APIs – as a result of they aren’t protected towards runtime entry. Because of this attackers can disable essential safety mechanisms from a user-mode course of with administrator privileges.

However nonetheless, if there are some readers interested by how it may be carried out by invoking the SW SMI handler, right here is the CHIPSEC command that can be utilized to create the ChgBootSecureBootDisable variable:

chipsec_util.py smi ship 0 0xCA 0x53 0x53CA 0x1D 0 0xB2

ChgBootDxeHook evaluation

Thus far, we all know that attackers would want to create the suitable ChgBoot* UEFI variable to disable UEFI Safe Boot or restore manufacturing unit UEFI Safe Boot keys in the course of the boot. So how does it work underneath the hood? This performance is dealt with by the ChgBootDxeHook DXE Driver and the entire ChgBoot* UEFI variables are being checked in its sub_3370 perform proven in Determine 11.

Determine 11. Hex-Rays-decompiled perform from ChgBootDxeHook checking ChgBoot variables.

To see how the UEFI Safe Boot is being disabled, we are able to look contained in the ChgBootSecureBootDisableCheck perform (precisely the identical additionally occurs within the ChgBootChangeLegacyCheck perform, simply with a distinct variable being checked).

As we are able to see in Determine 12, the perform checks for the existence of the ChgBootSecureBootDisable UEFI variable utilizing runtime providers GetVariable perform and in case it exists — no matter its worth — executes a perform we named DisableSecureBoot.

Determine 12. Hex-Rays-decompiled perform from ChgBootDxeHook checking the existence of ChgBootSecureBootDisable NVRAM variable

Right here is the place the magic occurs – as you may see in Determine 13 , this perform does two issues:

  • Units byte worth of the Setup UEFI variable at offset 0x4D9 to zero; this byte appears to be an indicator of the UEFI Safe Boot standing contained in the BIOS Setup utility.
  • Invokes protocol perform (protocol GUID C706D63F-6CCE-48AD-A2B4-72A5EF9E220C or LENOVO_SECURE_BOOT_SERVICES_PROTOCOL_GUID in Determine 13) put in by the SecureBootService DXE driver with a parameter figuring out an operation to be carried out, on this case the operation recognized by the worth 0x02 – which implies the disabling of UEFI Safe Boot.

Determine 13. Hex-Rays-decompiled code from ChgBootDxeHook liable for disabling UEFI Safe Boot

And the way does this perform from LENOVO_SECURE_BOOT_SERVICES_PROTOCOL disable UEFI Safe Boot? It does so by invoking the SW SMI handler 0xEC registered by VariableRuntimeDxe mixed SMM/DXE driver, which in flip units the authenticated UEFI variable named SecureBootEnforce (namespace EFI_GENERIC_VARIABLE_GUID) to 0x00.

Nevertheless, on some affected fashions (for example on the Lenovo V14-IIL), it’s not that straightforward and simply making a ChgBootSecureBootDisable UEFI variable gained’t disable UEFI Safe Boot. So, what’s the catch?

As we are able to see in Determine 14, after the ChgBootSecureBootDisable variable verify, one other situation is current – it disables UEFI Safe Boot provided that the worth retrieved from the particular LenovoVariable persistent storage, accessed utilizing a protocol recognized by the GUID C20E5755-1169-4C56-A48A-9824AB430D00 (LENOVO_VARIABLE_PROTOCOL_GUID in Determine 14), accommodates worth Y (0x59).

Determine 14. Hex-Rays-decompiled code – Disable UEFI Safe Boot with further LenovoVariable verify

For fashions together with this verify, greater privileges are required to disable safe boot from the OS, however it’s nonetheless potential by invoking the SW SMI handler registered by the LenovoVariableSmm SMM module.

An outline of this LenovoVariable persistent storage is obtainable within the subsequent part.

CVE-2021-3970 – Arbitrary SMM learn/write

On this final part, we’re going to have a look at the evaluation of the CVE-2021-3970 vulnerability attributable to an improper enter validation within the SW SMI handler perform, which may result in the arbitrary learn/write from/to the SMRAM and subsequent arbitrary code execution in SMM execution mode.

This vulnerability will be exploited from a privileged kernel-mode course of by triggering the software program SMI interrupt and passing a bodily tackle of a specifically crafted buffer as a parameter to the weak SW SMI handler.

On this evaluation, we’ll work with the firmware picture (model 7XCN41WW) of the Lenovo 330-15IGM, which is affected by the CVE-2021-3970 vulnerability.

Lenovo variable storage and a weak SW SMI handler

The firmware on sure Lenovo client laptop computer fashions implements a particular LenovoVariable persistent storage, permitting information storage of as much as 4KB in SPI flash.

It’s utilized by the platform firmware to retailer varied info, together with the Lenovo product title, motherboard mannequin title and model, OEM OS license, or as talked about within the part above, in some instances it may be used to activate the ChgBootDxeHook driver so as to disable UEFI Safe Boot characteristic.

Within the firmware we analyzed, the SMM model of the Lenovo variable’s performance is offered to different drivers by the protocol BFD02359-8DFE-459A-8B69-A73A6BAFADC0 (let’s title it LENOVO_VARIABLE_PROTOCOL_GUID) and it’s put in by the LenovoVariableSmm SMM module.

This LENOVO_VARIABLE_PROTOCOL’s interface gives 4 capabilities:

  1. Learn – Learn information from a Lenovo variable
  2. Write – Write information right into a Lenovo variable
  3. Lock – Lock a Lenovo variable for write
  4. Unlock – Unlock a Lenovo variable for write

It is very important word that LenovoVariableSmm not solely installs this protocol to be accessible by different SMM modules, however it additionally registers the SW SMI handler perform that permits accessing this storage from the OS by invoking SW SMI. The worst half is that it doesn’t correctly validate parameters handed to the SW SMI handler, which may end up in arbitrary learn/write from/to the SMRAM.

Determine 15. Hex-Rays-decompiled code of SW SMI handler perform registered by the LenovoVariableSmm module

Trying carefully on the SW SMI handler perform in Determine 15, we see that it begins with studying the person parameters from the CPU saved state registers – that are registers saved for the time being of SMI invocation.

These two arguments are being learn:

  1. 64-bit bodily tackle constructed from the values saved within the ECX and EDI registers.
  2. The command, indicating the motion to be executed (learn, write, delete, and so forth.), from the BX register.

This bodily tackle handed as an argument to the SMI handler ought to comprise information figuring out the Lenovo variable to be learn or written; the construction of this buffer is proven in Determine 16.

Determine 16. Construction of the buffer handed to the LenovoVariableSmm SW SMI handler

The buffer begins with the 0x20-byte header (LENV_HDR), containing the distinctive GUID that identifies the Lenovo variable and a 32-bit worth specifying the size of the info to be retrieved from the variable or written to it. The reminiscence house positioned instantly after the header is used as a supply or vacation spot location for LENOVO_VARIABLE_PROTOCOL’s Learn and Write capabilities.

The issue is, the bodily tackle offered by the caller shouldn’t be validated or checked in any means and it’s immediately handed as an argument to the LENOVO_VARIABLE_PROTOCOL capabilities (see line 41 in Determine 15). This permits an attacker to cross any bodily tackle – together with an tackle from the SMRAM vary.

However how may this be utilized by an attacker to learn/write from/into the SMRAM? To learn the SMRAM content material, the next steps are required:

  1. Discover the SMRAM bodily tackle.
  2. Copy the LENV_HDR header to the bodily tackle 32 bytes earlier than the SMRAM – the header ought to comprise a variable identifier (it may be a random GUID) and the size of the info one wish to learn from SMRAM (the utmost is one thing beneath 4KB).
  3. Invoke SW SMI registered by the LenovoVariableSmm (SwSmiNumber 0x80), specifying the command with ID 0x02 within the BX register (that means that you just need to write into the Lenovo variable) and the tackle of beforehand created header within the ECX and EDI registers (to inform the SW SMI handler what you need to write into that variable).
  4. Now, that variable accommodates a specified quantity of SMRAM information – so we solely have to learn it. We allocate a brand new buffer (equal to the scale of the header plus the scale of knowledge to retrieve) and duplicate the identical header into it, as utilized in step 2.
  5. Invoke the SW SMI handler once more, specifying the command with ID 0x01 in BX register (that means that you just need to learn from the Lenovo variable) and the tackle of our newly allotted buffer from step 4 within the ECX and EDI registers (to inform the SW SMI handler the place we need to copy the content material of the Lenovo variable – which at this second accommodates information from the SMRAM).

An instance of the above-described steps utilizing the CHIPSEC framework is proven in Determine 17; the output of the script containing the primary 0x100 bytes of the SMRAM is proven in Determine 18.

Determine 17. CHIPSEC instance – learn 0x100 bytes from SMRAM by exploiting CVE-2021-3972

Determine 18. CHIPSEC script output dumping the primary 0x100 bytes of SMRAM

To have the ability to write into SMRAM, the precept is sort of the identical – first, the attackers want to write down their very own information into the Lenovo variable, after which learn the info from the variable on to the SMRAM.

We now have offered an instance of learn how to learn solely the primary 0x100 bytes of the SMRAM; nevertheless, with further modifications, it’s potential to learn/write the entire SMRAM vary. This might permit risk actors to execute their very own malicious code in SMM and even worse – contemplating the LenovoVariable SW SMI handler’s capability to change the SPI flash – write the attackers’ personal malicious firmware implant on to the SPI flash.


UEFI threats will be extraordinarily stealthy and harmful. They’re executed early within the boot course of, earlier than transferring management to the working system, which implies that they will bypass virtually all safety measures and mitigations greater within the stack that would stop their OS payloads from being executed. So, how do UEFI threats overcome all the safety protections which were created to stop deployment or execution of UEFI threats themselves?

All the real-world UEFI threats found lately (LoJax, MosaicRegressor, MoonBounce, ESPecter, FinSpy) wanted to bypass or disable the safety mechanisms in a roundabout way so as to be deployed and executed. Nevertheless, solely within the case of LoJax, the primary in-the-wild UEFI rootkit (found by ESET Analysis in 2018), do we’ve got a clue the way it was carried out – through the use of the ReWriter_binary able to exploiting the Speed Racer vulnerability.

Despite the fact that vulnerabilities aren’t the one possibility for turning off or bypassing firmware safety mitigations, there are numerous such vulnerabilities and as a result of variety of completely different firmware implementations and their complexity, many extra are doubtless simply ready to be found.

Solely within the final 12 months, we’ve got seen quite a few high-impact UEFI firmware vulnerabilities being publicly disclosed. Most notable are these by the researchers from Binarly, of their An In-Depth Look At The 23 High-Impact Vulnerabilities and 16 High Impact Vulnerabilities Discovered In HP Devices blogposts, and by researchers from SentinelOne of their Another Brick in the Wall: Uncovering SMM Vulnerabilities in HP Firmware blogpost.

Our discovery, along with the above-mentioned ones, demonstrates that in some instances, deployment of UEFI threats won’t be as troublesome as anticipated, and the bigger variety of real-world UEFI threats found within the final years means that adversaries are conscious of this.

Relating to the vulnerabilities described on this blogpost, we strongly advise all house owners of Lenovo laptops, to undergo the record of affected units and replace their firmware, ideally by following the manufacturer’s instructions.

For these utilizing Finish Of Improvement Help (EODS) units affected by the CVE-2021-3972, with none fixes accessible: one factor that may assist you to defend towards undesirable modification of the UEFI Safe Boot state is utilizing a TPM-aware full-disk encryption answer able to making disk information inaccessible if the UEFI Safe Boot configuration modifications.

Posted in SecurityTags:
Write a comment