Zero-day vulnerabilities are tremendous lively and Google and Apple are performing to patch these vulnerabilities, a few of which seen on-the-wild.
Google and Apple are each launch patches for zero-day vulnerabilities which have already been exploited within the wild. ESET cybersecurity knowledgeable Tony Anscombe explains what these vulnerabilities are in less complicated phrases, and reiterate the significance of conserving all of your apps and units up-to-date to remain cybersafe.
ESET researchers uncover a number of vulnerabilities in numerous 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 numerous Lenovo shopper 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 throughout the manufacturing strategy of Lenovo shopper 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 function from a privileged user-mode course of throughout OS runtime. It signifies 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 gadgets.
To grasp how we had been capable of finding these vulnerabilities, think about the firmware drivers affected by CVE‑2021-3971. These drivers instantly caught our consideration by their very unlucky (however surprisingly sincere) names: SecureBackDoor and SecureBackDoorPeim. After some preliminary evaluation, we found different Lenovo drivers sharing a number 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 might 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 checklist of affected gadgets accommodates a couple of hundred totally different shopper laptop computer fashions with thousands and thousands 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 checklist of affected fashions with energetic improvement help is printed within the Lenovo Advisory.
Along with the fashions listed within the advisory, a number of different gadgets we reported to Lenovo are additionally affected, however received’t be mounted as a consequence of them reaching Finish Of Growth Help (EODS). This contains gadgets the place we noticed reported vulnerabilities for the primary time: Ideapad 330-15IGM and Ideapad 110-15IGR. The checklist of such EODS gadgets that we have now been in a position to determine might 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 – as a consequence of encountering improvement points
2022-04-18: Lenovo safety advisory printed
2022-04-19: ESET Analysis blogpost printed
UEFI firmware theoretical fundamentals
Earlier than we begin with the evaluation of the reported vulnerabilities, we want to present an introduction to the essential principle of UEFI protocols, System Administration Mode, UEFI NVRAM variables, UEFI Safe Boot, and primary SPI flash write safety.
Be aware that our goal is to clarify 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 subjects, we propose leaping on to the Technical evaluation part. For many who think about this introduction inadequate, we extremely suggest wanting into the series of blogposts written by researchers from SentinelOne and the UEFI Specification.
UEFI companies and protocols
UEFI defines two forms of companies for use by UEFI drivers and functions – Boot (EFI_BOOT_SERVICES) and Runtime (EFI_RUNTIME_SERVICES) companies. Each are handed to the driving force’s or utility’s entry level by way of the EFI_SYSTEM_TABLE argument.
They supply the essential features and knowledge buildings crucial for the drivers and functions to do their job, similar to 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 features 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 known as. The UEFI specification defines many such protocols to cowl the commonest firmware use-case situations, however firmware builders are nonetheless in a position to outline their very own protocols to increase this primary performance.
UEFI variables
UEFI variables are a particular firmware storage mechanism utilized by UEFI modules to retailer numerous configuration knowledge, together with boot configuration, UEFI Safe Boot settings, certificates, and comparable knowledge. These variables are all the time recognized by a variable identify and a namespace (GUID).
When making a UEFI variable, attributes are used to point how the variable needs to be saved and maintained by the system – this manner one could make variables persistent (surviving energy cycles), short-term, and even authenticated. Authenticated within the context of the NVRAM variables signifies that the variable content material will be modified provided that the brand new variable knowledge is appropriately signed by the licensed non-public key – learn entry to the variable is allowed to anybody.
Examples of a few of these attributes observe; right here we checklist solely crucial ones:
VARIABLE_ATTRIBUTE_NON_VOLATILE (NV)(0x00000001) Variables utilizing this attribute persist throughout the ability cycles and are saved in mounted {hardware} storage (NVRAM) with restricted capability (usually round 64MB).
VARIABLE_ATTRIBUTE_BOOTSERVICE_ACCESS (BS)(0x00000002) If the BS attribute is ready, variables with out the RT attribute set is not going to be seen to the GetVariable perform after the execution of EFI_BOOT_SERVICES.ExitBootServices.
VARIABLE_ATTRIBUTE_RUNTIME_ACCESS (RT)0x00000004) To entry a variable by way of the GetVariable perform after the execution of EFI_BOOT_SERVICES.ExitBootServices, the RT attribute have to be set.
A full checklist 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 features are:
System Administration Mode (SMM)
SMM is a extremely privileged execution mode of x86 processors, sometimes called “ring ‑2”.
SMM code is written inside the context of the system firmware and is often used for numerous duties together with superior energy administration, execution of OEM proprietary code, and safe firmware updates. It gives an impartial execution atmosphere fully invisible to the working working system, and the code and knowledge utilized in SMM are saved in hardware-protected reminiscence – accessible solely from SMM – known as SMRAM.
To enter SMM, a particular processor interrupt known 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 adequate to know that one of many methods to generate an SMI (particularly a software program SMI – SW SMI) and enter SMM on Intel structure techniques is to put in writing to I/O port 0xB2 (utilizing the OUT instruction). That is typically utilized by software program to invoke firmware companies throughout system runtime.
Defining SW SMI handlers within the UEFI firmware
To grasp 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).
As written within the specification, this protocol can be utilized by SMM modules to put in handler features 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.
This service installs a DispatchFunction perform that might be known as when the software program SMI supply specified by RegisterContext‑>SwSmiInputValue is detected. In different phrases, this DispatchFunction might be known 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 features ReadSaveState and WriteSaveState, respectively.
Major SPI flash safety mechanisms
UEFI firmware often resides within the embedded flash reminiscence chip situated 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 just isn’t affected by working system reinstallation and due to this fact presents a tempting goal for menace 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. Be aware that though they could be named in a different way on different chipsets, the precept is identical.
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.
BLE (bit 1)
When set, BIOSWE could possibly be set from 0 to 1 solely by SMM code. Any try and set BIOSWE from non-SMM code will set off SMI. This gives a possibility for the OEM to implement an SMI handler to guard the BIOSWE bit by setting it again to 0.
SMM_BWP (bit 5)
When set, the BIOS area just isn’t writable until 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 device, which was utilized by the Sednit group to deploy LoJax).
Protected Vary registers (PR0-PR4)
Every register specifies impartial learn/write permissions for a selected 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 just isn’t set.
This FLOCKDN bit needs to be set by the platform firmware throughout platform initialization – proper after setting the Protected Vary (PR) registers. As soon as FLOCKDN is ready, it’s cleared solely after the subsequent {hardware} reset. It signifies 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 reputable firmware updates have to be carried out earlier than PR registers are locked.
Options accessible on present techniques
Fashionable techniques these days often include options offering hardware-based boot integrity (similar to Intel Boot Guard) which, if configured correctly and with out extra vulnerabilities, protects from booting untrusted firmware code even when the above-mentioned chipset-provided protections fail to guard the SPI flash as a consequence of misconfiguration or vulnerability.
entry PCI/PCIe configuration house
The BIOS Management Register, Safety Vary registers, and lots of different configuration registers will be learn or written by accessing the PCI(e) configuration house. The situation (or handle) of the PCI(e) configuration house for the precise PCI-compatible gadgets (e.g., SPI flash) is specified by the three values:
Configurations associated to this gadget are situated 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 knowledge in PCI configuration house. As it’s not crucial for the aim of our blogpost, we is not going to be diving into the main points right here.
Utilizing Reminiscence Mapped I/O (MMIO)
When utilizing Reminiscence-Mapped I/O, the PCI configuration house is mapped on to major reminiscence handle house; due to this fact, the configuration knowledge will be accessed virtually the identical means as another knowledge. All that must be identified is the PCI handle of the specified knowledge, so the place can we discover this handle? We will assemble it on our personal if we all know:
the MMIO base handle (will be discovered inside MCFG ACPI desk)
Bus, System, Perform, and Offset (additionally known as Register) values figuring out the information that we need to entry (you will discover them in a chipset’s datasheet).
An instance of the macro encoding these values into PCI handle will be present in EDK2’s PciLib.h header file. Alternatively, a Python implementation of the features translating MMIO PCI handle to particular person identifiers and vice versa is proven in Determine 3.
# returns handle relative to the PciExpressBaseAddress
Determine 3. PCI handle encoding/decoding in Python
UEFI Safe Boot
UEFI Safe Boot is outlined within the UEFI specification, and its major goal 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 might be included on this verification course of is determined by the UEFI Safe Boot coverage implementation within the particular platform – typically, solely third-party UEFI drivers, functions and OPROMs are being verified, and the drivers on the SPI flash are implicitly thought of trusted.
To resolve what’s trusted and what’s not, UEFI Safe Boot makes use of particular databases saved within the authenticated NVRAM variables, specifically db and dbx.
The db database accommodates an inventory of trusted public key certificates which are licensed to authenticate boot part signatures or, along with the certificates, it will probably additionally include an inventory of hashes of the elements which are 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 are not allowed to be executed – to forestall execution of signed executables with identified 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.
In the beginning 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 check with this GUID as LENOVO_BACKDOOR_NAMESPACE_GUID).
We’ll 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 accountable for the establishing BIOS Management Register and Protected Vary register-based SPI flash protections.
In consequence, the exploited system will permit modification of the SPI flash even when executed from non-SMM code and thus permit an attacker to deploy malicious code on to the firmware storage.
This “Disable SPI flash protections function” is carried out by the next drivers within the firmware of affected laptops:
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!
Namespace GUID: LENOVO_BACKDOOR_NAMESPACE_GUID
Attributes: NV + BS + RT (0x00000007)
Worth: Any non-null byte
after which restart the affected gadget.
To grasp how straightforward 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 gadgets 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 known as the Pre-EFI Initialization (PEI) section. Throughout this section, Pre-EFI Initialization Modules (PEIMs) are executed to carry out numerous duties together with initialization of everlasting reminiscence and invocation of the subsequent boot section – Driver Execution Atmosphere (DXE). To cross info from the PEI section to the DXE section, particular knowledge buildings known as Hand-Off Blocks (HOBs) are used.
SecureBackDoorPeim is a PEI module accountable for each studying the content material of the UEFI variable cE!, which belongs to the namespace LENOVO_BACKDOOR_NAMESPACE_GUID, and making ready the proper HOB knowledge construction to cross its worth to the SecureBackDoor DXE section driver.
It does so in three easy steps, as proven in Determine 4.
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.
To cross this info to the SecureBackDoor DXE driver, create a HOB knowledge construction recognized by the next GUID AD7934E7-D800-4305-BF6F-49ED9918E1AB. To make issues easier, let’s identify this HOB knowledge construction GUID SECURE_BACKDOOR_HOB_GUID.
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 accountable for deactivating SPI flash protections if it finds a HOB recognized by SECURE_BACKDOOR_HOB_GUID within the HOB checklist. In Determine 5 we are able to see that to search out this HOB, it walks by means of the checklist 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-decompiledSecureBackDoor code accountable for discovering HOB created bySecureBackdoorPeim
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 totally 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 grasp the way it really disables SPI flash protections, we have to look into two totally different firmware drivers:
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 ready, by performing a bitwise AND operation with worth 0x08 (which is 0b1000 in binary illustration).
Determine 6. Hex-Rays-decompiled code fromPchBiosWriteProtect accountable for initialization of BIOS Management Register – associated SPI flash protections
If it’s not set, it skips a number of traces of code which are accountable for:
Performing MMIO learn operation (line 15 in Determine 6) by studying a 32-bit worth from the handle 0xE00F8054. If we cross this handle as an argument to the Python perform pci_decode_from_addr, which we launched within the Determine 3: that perform will print the handle, decoded as Bus: 0, System: 0x1F, Perform: 0, Offset: 0x54. Primarily based on these values and realizing 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 handle (SBASE), 32-bit PCI configuration register containing the handle 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 under, we see that it’s accountable for setting bit 5 contained in the register situated 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 DispatchFunctionfromPchBiosWriteProtect
Ultimately, DispatchFunction can be accountable 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 ready. In that case, the put in handler will set BIOSWE (or WPD for our chipset) bit again to 0.
In consequence, 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 accountable 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 resolve 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 just isn’t set, it is going to merely skip code accountable for setting these registers and thus go away SPI flash unprotected.
Determine 8. Hex-Rays-decompiled code accountable for setting the Protected Vary registers
The subsequent vulnerability we’ll check out is the CVE-2021-3972. This vulnerability permits an attacker with elevated privileges to vary numerous 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.
Evidently, such an motion would have severe influence on system safety. Disabling UEFI Safe Boot would imply that the firmware received’t implement integrity verification of the UEFI drivers and functions throughout 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 might expose a system to the chance of deploying some UEFI functions, similar to bootloaders, with identified 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
Namespace GUID: LENOVO_BACKDOOR_NAMESPACE_GUID
Attributes: NV + BS + RT (0x00000007)
Worth: Any non-null byte
and restart the laptop computer.
As an example how straightforward 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 “function” is carried out by the next two drivers within the firmware of affected gadgets:
ChgBootSmm is an SMM module accountable 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. Which means one can set off execution of this perform by writing the worth 0xCA to I/O port 0xB2.
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 features SmmGetVariable and SmmSetVariable to learn from and write into numerous UEFI variables and the choice of what variable might be created or modified is made primarily based on the worth from RBX register saved state.
Determine 10. Hex-Rays-decompiled code of SW SMI handler put in by theChgBootSmm driver
Furthermore, every written variable has the identical attributes bitmask – 0x00000007 (NV|BS|RT) – which means that the entire variables created might be saved in non-volatile storage and thus survive an influence cycle.
The total checklist of the variables that may be accessed utilizing this SW SMI handler are:
Namespace: LENOVO_BACKDOOR_NAMESPACE_GUID
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. Normally their names are fairly self-explanatory and from the safety perspective, the next are essentially the most attention-grabbing:
ChgBootSecureBootDisable and ChgBootChangeLegacy If created (any of them), ChgBootDxeHook disables the UEFI Safe Boot function throughout the subsequent boot.
ChgBootRestoreFactory If created, ChgBootDxeHook restores manufacturing unit default values for UEFI Safe Boot variables PK, KEK, db, and dbx throughout the subsequent boot. This may 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 include the most recent revocation information. The latter might expose the system to the chance of deploying some UEFI functions, similar to bootloaders, with identified 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. Which means attackers can disable essential safety mechanisms from a user-mode course of with administrator privileges.
However nonetheless, if there are some readers keen on how it may be executed by invoking the SW SMI handler, right here is the CHIPSEC command that can be utilized to create the ChgBootSecureBootDisable variable:
Up to now, we all know that attackers would wish to create the suitable ChgBoot* UEFI variable to disable UEFI Safe Boot or restore manufacturing unit UEFI Safe Boot keys throughout 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.
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 unique 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 companies GetVariable perform and in case it exists — no matter its worth — executes a perform we named DisableSecureBoot.
Determine 12. Hex-Rays-decompiled perform fromChgBootDxeHookchecking the existence of ChgBootSecureBootDisableNVRAM variable
Right here is the place the magic occurs – as you’ll be able to 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 accountable 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.
Nonetheless, on some affected fashions (as an example on the Lenovo V14-IIL), it’s not that easy and simply making a ChgBootSecureBootDisable UEFI variable received’t disable UEFI Safe Boot. So, what’s the catch?
As we are able to see in Determine 14, after the ChgBootSecureBootDisable variable test, 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 extraLenovoVariable test
For fashions together with this test, larger 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 take a look at the evaluation of the CVE-2021-3970 vulnerability brought on by an improper enter validation within the SW SMI handler perform, which might 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 handle 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 shopper laptop computer fashions implements a particular LenovoVariable persistent storage, permitting knowledge storage of as much as 4KB in SPI flash.
It’s utilized by the platform firmware to retailer numerous info, together with the Lenovo product identify, motherboard mannequin identify 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 with a purpose to disable UEFI Safe Boot function.
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 identify it LENOVO_VARIABLE_PROTOCOL_GUID) and it’s put in by the LenovoVariableSmm SMM module.
This LENOVO_VARIABLE_PROTOCOL’s interface gives 4 features:
Learn – Learn knowledge from a Lenovo variable
Write – Write knowledge right into a Lenovo variable
Lock – Lock a Lenovo variable for write
Unlock – Unlock a Lenovo variable for write
You will need to notice that LenovoVariableSmm not solely installs this protocol to be accessible by different SMM modules, however it additionally registers the SW SMI handler perform that enables 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 can lead to arbitrary learn/write from/to the SMRAM.
Determine 15. Hex-Rays-decompiled code of SW SMI handler perform registered by the LenovoVariableSmmmodule
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 in the mean time of SMI invocation.
These two arguments are being learn:
64-bit bodily handle constructed from the values saved within the ECX and EDI registers.
The command, indicating the motion to be executed (learn, write, delete, and so forth.), from the BX register.
This bodily handle handed as an argument to the SMI handler ought to include knowledge 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 theLenovoVariableSmmSW 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 information to be retrieved from the variable or written to it. The reminiscence house situated instantly after the header is used as a supply or vacation spot location for LENOVO_VARIABLE_PROTOCOL’s Learn and Write features.
The issue is, the bodily handle offered by the caller just isn’t validated or checked in any means and it’s immediately handed as an argument to the LENOVO_VARIABLE_PROTOCOL features (see line 41 in Determine 15). This enables an attacker to cross any bodily handle – together with an handle from the SMRAM vary.
However how might this be utilized by an attacker to learn/write from/into the SMRAM? To learn the SMRAM content material, the next steps are required:
Discover the SMRAM bodily handle.
Copy the LENV_HDR header to the bodily handle 32 bytes earlier than the SMRAM – the header ought to include a variable identifier (it may be a random GUID) and the size of the information one want to learn from SMRAM (the utmost is one thing under 4KB).
Invoke SW SMI registered by the LenovoVariableSmm (SwSmiNumber 0x80), specifying the command with ID 0x02 within the BX register (which means that you simply need to write into the Lenovo variable) and the handle of beforehand created header within the ECX and EDI registers (to inform the SW SMI handler what you need to write into that variable).
Now, that variable accommodates a specified quantity of SMRAM knowledge – so we solely must learn it. We allocate a brand new buffer (equal to the dimensions of the header plus the dimensions of information to retrieve) and duplicate the identical header into it, as utilized in step 2.
Invoke the SW SMI handler once more, specifying the command with ID 0x01 in BX register (which means that you simply need to learn from the Lenovo variable) and the handle 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 knowledge 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 nearly the identical – first, the attackers want to put in writing their very own knowledge into the Lenovo variable, after which learn the information from the variable on to the SMRAM.
We have now offered an instance of the right way to learn solely the primary 0x100 bytes of the SMRAM; nonetheless, with extra modifications, it’s potential to learn/write the entire SMRAM vary. This might permit menace actors to execute their very own malicious code in SMM and even worse – contemplating the LenovoVariable SW SMI handler’s capacity to switch the SPI flash – write the attackers’ personal malicious firmware implant on to the SPI flash.
Conclusion
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 signifies that they’ll bypass virtually all safety measures and mitigations larger within the stack that might forestall their OS payloads from being executed. So, how do UEFI threats overcome all the safety protections which have been created to forestall deployment or execution of UEFI threats themselves?
All the real-world UEFI threats found in recent times (LoJax, MosaicRegressor, MoonBounce, ESPecter, FinSpy) wanted to bypass or disable the safety mechanisms not directly with a purpose to be deployed and executed. Nonetheless, solely within the case of LoJax, the primary in-the-wild UEFI rootkit (found by ESET Analysis in 2018), do we have now a clue the way it was executed – through the use of the ReWriter_binary able to exploiting the Speed Racer vulnerability.
Although vulnerabilities aren’t the one possibility for turning off or bypassing firmware safety mitigations, there are a lot of such vulnerabilities and because of the variety of totally different firmware implementations and their complexity, many extra are seemingly simply ready to be found.
Our discovery,along with the above-mentioned ones, demonstrates that in some instances, deployment of UEFI threats may not be as tough as anticipated, and the bigger variety of real-world UEFI threats found within the final years means that adversaries are conscious of this.
Concerning the vulnerabilities described on this blogpost, we strongly advise all homeowners of Lenovo laptops, to undergo the checklist of affected gadgets and replace their firmware, ideally by following the manufacturer’s instructions.
For these utilizing Finish Of Growth Help (EODS) gadgets affected by the CVE-2021-3972, with none fixes accessible: one factor that may show you how to shield towards undesirable modification of the UEFI Safe Boot state is utilizing a TPM-aware full-disk encryption answer able to making disk knowledge inaccessible if the UEFI Safe Boot configuration adjustments.
