---

If you’ve ever wondered how low-level vulnerabilities can punch holes in the world’s most trusted laptops, CVE-2022-1107 is a case worth seeing. In this post, we'll take a journey from how this bug was found, to how it might be abused, peppered with code samples, links, and steps a motivated attacker might follow. No unnecessary jargon — just the meat of the exploit.

What is CVE-2022-1107?

CVE-2022-1107 is a vulnerability affecting specific Lenovo ThinkPad models. It was uncovered during an internal security audit, which found that the SmmOEMInt15 System Management Interrupt (SMI) handler—a key piece of firmware—was inappropriately using Boot Services. This is a big deal because SMI handlers run in the system’s privileged System Management Mode (SMM), way below the operating system. If someone finds a way to poke at SMM with bad data, they could run code with the highest permissions a PC allows.

Vulnerable Component: SmmOEMInt15 SMI handler.

- Attack Vector: Requires local access with elevated privileges (such as admin or SYSTEM on Windows).
- Impact: Lets an attacker potentially run arbitrary code in SMM, leading to full system compromise.

How Does the SmmOEMInt15 SMI Handler Work?

System Management Interrupt handlers are designed to serve firmware-level functions, often handling stuff even before Windows or Linux boots. The problem here is that the SmmOEMInt15 handler trusts input from Boot Services—essentially, early UEFI routines that aren’t supposed to mix with SMM at runtime.

When the SMI handler receives a call (via port writes or a specific protocol), it performs its tasks, sometimes by accessing or modifying system resources based on values it receives — and that’s where Boot Services overlaps can be dangerous.

What Went Wrong?

The vulnerability boils down to this: The SmmOEMInt15 SMI handler expected only trusted input from Boot Services. But after the system boots, the OS (even a malicious one) can craft requests that look like they're from Boot Services. The handler doesn’t properly validate these requests or pointers, opening a door.

If you’re running code as root/Administrator, you can make a crafted call to this handler, passing info or memory pointers it will process. Since it’s running in SMM, your data can become code that the firmware executes at ring -2.

What you need to achieve exploitation

- Local administrator/root privileges.

High-level Exploit Flow

1. Gain Local Admin: Elevate yourself to SYSTEM/root if not already (for the ability to talk to SMM).

Trigger SMI: Use a crafted SMI request to the SmmOEMInt15 handler, pointing it to your payload.

4. SMM Executes Payload: Handler processes your request; executes your code; you now “own” the box at the firmware level.

Example Proof-of-Concept (POC) in C

Let’s imagine we’re an attacker on Windows, and there’s a driver interface that lets us trigger system management interrupts (common for things like WMI or vendor update agents). Here’s a *conceptual* C snippet for triggering an SMI (with crucial detail omitted for safety):

#include <windows.h>
#include <stdio.h>

#define SMM_BUFFER_SIZE x100

int main() {
    // Open handle to sys device that allows triggering SMM (pseudo)
    HANDLE hDevice = CreateFileA("\\\\.\\SMMDevice", GENERIC_READ|GENERIC_WRITE, , NULL, OPEN_EXISTING, , NULL);
    if (hDevice == INVALID_HANDLE_VALUE) {
        printf("Failed to open SMM device\n");
        return 1;
    }

    // Allocate buffer shared with SMM
    BYTE* maliciousBuffer = (BYTE*)VirtualAlloc(NULL, SMM_BUFFER_SIZE, MEM_COMMIT, PAGE_READWRITE);
    // Prepare payload in maliciousBuffer

    // Example: Set up SmmOEMInt15-specific structure
    ((DWORD*)maliciousBuffer)[] = xDEADBEEF; // Crafted command ID or address

    DWORD bytesReturned;
    BOOL res = DeviceIoControl(
        hDevice, 
        xDEADBEEF, // IOCTL code for SMI (placeholder)
        maliciousBuffer, 
        SMM_BUFFER_SIZE,
        NULL, 
        , 
        &bytesReturned, 
        NULL
    );

    if (res) {
        printf("SMI triggered successfully!\n");
    } else {
        printf("Failed to trigger SMI.\n");
    }

    CloseHandle(hDevice);
    VirtualFree(maliciousBuffer, , MEM_RELEASE);
    return ;
}

NOTES:
- In this code, \\.\SMMDevice and IOCTL code xDEADBEEF are placeholders. You’d need to reverse actual sys drivers or UEFI protocols to find the correct handles and codes — not usually hard for a determined attacker with admin.
- The actual crafting of the buffer would depend on SMM handler specifics, which are available via reverse engineering.

Why Is This a Big Deal?

- SMM is god mode: It can bypass kernel security, tamper TPM secrets, or install ultra-persistent rootkits.

Mitigation

1. Update Firmware: Lenovo firmware security advisory contains links to the patched BIOS for affected models.
2. Prevent Privilege Escalation: Don’t give up admin rights lightly. Local attackers still need to elevate first.
3. Monitor SMM Calls: Some EDR tools can flag unusual SMM traffic or block unknown drivers from triggering SMI.

References & Further Reading

- Lenovo Security Advisory: CVE-2022-1107 (April 2022)
- NIST NVD Entry
- OpenSecurityTraining: UEFI and SMM

Final Words

Firmware bugs like CVE-2022-1107 are hard to find, harder to fix, and really hard to eradicate if someone gets in. If you use an affected ThinkPad model, update your firmware as soon as possible. Attackers are increasingly aiming below the OS — don’t give them a way in.

If you’re interested in learning more about SMM, UEFI, and firmware hacking, check out the links above. And stay updated — your security depends on it.


*Share with anyone who manages ThinkPads or just likes good technical detective stories!*

Timeline

Published on: 04/22/2022 21:15:00 UTC
Last modified on: 05/12/2022 13:42:00 UTC