CVE-2022-32267 is a security vulnerability in certain Insyde BIOS platforms, specifically involving the SmmResourceCheckDxe driver. This vulnerability opens the door to a serious attack: DMA-based SMRAM corruption through a TOCTOU (Time-Of-Check to Time-Of-Use) exploit. In this post, we'll break down what this means, how the exploit works, and what has been done to fix this issue.
What is the SmmResourceCheckDxe Driver?
The SmmResourceCheckDxe driver is a part of the System Management Mode (SMM) in UEFI firmware. It helps protect System Management RAM (SMRAM), a special memory region used for handling low-level system operations.
The driver uses a Software System Management Interrupt (SMI) handler to process certain inputs. The vulnerability arises because the handler doesn't always check these inputs in a secure way.
Technical Overview of the Vulnerability
The vulnerability happens when Direct Memory Access (DMA) transactions target the input buffers that the SMI handler uses. Because these buffers live outside protected memory, a malicious component (like a rogue PCI device or compromised OS kernel driver) can race to change the buffer's contents while the SMI handler is reading them.
Time-of-Use (TOU): Before actual use, a DMA transaction modifies that buffer.
3. The SMI handler now operates on data that is not what it originally checked, possibly causing it to write outside its intended memory area—corrupting SMRAM.
Here's an overly simplified pseudocode of the problem
// Vulnerable SMI handler code
void SmiHandler(VOID *InputBuffer) {
if (InputBuffer == NULL) return;
// TOC: Check buffer contents
if (IsValid(InputBuffer)) {
// DMA device changes InputBuffer here (attacker's TOCTOU)
// ...
// TOU: Use the buffer's data, possibly leading to SMRAM corruption
ProcessData(InputBuffer);
}
}
The attacker causes a DMA device to modify the buffer after IsValid() runs but before ProcessData() executes.
Let's see how a real-world attack might unfold
1. Preparation: The attacker identifies the memory region used as the input buffer for the SMI handler.
Trigger: They submit a legitimate SMI request, causing the handler to start processing.
3. Race Condition: Using a PCI device or a compromised kernel driver, the attacker issues a DMA write to the input buffer after it has been validated but before it’s fully processed.
4. Corruption: The SMM handler, trusting the now-modified buffer, might overwrite arbitrary locations in SMRAM, execute malicious code, or otherwise compromise the security of the system firmware.
Example exploit sketch (kernel-level, for illustration)
// Userland triggers the SMI handler (e.g., writing to an IO port)
// Attacker's PCI device, upon seeing this trigger, quickly does:
dma_write(attacker_payload, smi_input_buffer_addr, sizeof(payload));
If timed correctly, this payload can alter execution flow in SMM—an extremely privileged and security-critical environment.
Why is this Dangerous?
- SMM is all-powerful: Exploiting SMRAM grants control over the entire platform, below the OS level.
Fixes and Patch Information
This vulnerability was discovered by Insyde engineering and fixed in multiple kernel versions. If you use Insyde BIOS, check your version and update!
Kernel 5.5: 05.52.23
Official security advisory:
Insyde Security Advisory SA-2022046
How Did They Fix It?
To mitigate TOCTOU attacks like this, firmware must copy SMI input buffers into SMRAM immediately, then validate and use only those copies. This closes the race window because DMA devices can't alter SMRAM.
Pseudo-fixed code
void SmiHandler(VOID *InputBuffer) {
if (InputBuffer == NULL) return;
// Secure step: Copy buffer to SMRAM first
CHAR8 SecureBuffer[MAX_SIZE];
CopyMem(SecureBuffer, InputBuffer, MAX_SIZE);
// Now validate and use only the secure buffer
if (IsValid(SecureBuffer)) {
ProcessData(SecureBuffer);
}
}
Additional Reading
- What is DMA? (Wikipedia)
- System Management Mode Explained
- Common TOCTOU attack patterns
Conclusion
CVE-2022-32267 reminds us that even deeply embedded firmware code can have subtle, severe weaknesses. With more research on BIOS/UEFI security, system builders must stay sharp by patching promptly and adopting best practices in buffer validation.
Check your BIOS updates and stay safe!
References:
- Insyde Security Advisory SA-2022046
- NIST NVD: CVE-2022-32267
Timeline
Published on: 11/15/2022 00:15:00 UTC
Last modified on: 11/18/2022 16:01:00 UTC