GHSA-HM2W-VR2P-HQ7W: Heap Out-of-Bounds Write in uefi-firmware-parser Tiano Decompressor

The uefi-firmware-parser library provides core functionality for extracting, parsing, and analyzing UEFI firmware volumes. To handle compressed EFI payloads efficiently, the library includes a native C extension that implements the Tiano and EFI decompression algorithms. This native implementation directly processes untrusted bitstreams extracted from firmware images.

A critical vulnerability exists within the Huffman table generation phase of the Tiano decompressor. The issue is classified as CWE-787 (Out-of-bounds Write) and occurs because the implementation fails to validate length values read from the compressed stream against the fixed sizes of internal data structures. This oversight creates a direct pathway for heap memory corruption.

The vulnerability is a legacy flaw resulting from porting older Tiano compression code without incorporating modern security hardening. Similar vulnerabilities were previously identified and addressed in upstream implementations like EDK2 (CVE-2017-5731 through CVE-2017-5735). The uefi-firmware-parser implementation remained unpatched against these known attack vectors until version 1.13.

The root cause of the vulnerability lies in the ReadCLen function located in uefi_firmware/compression/Tiano/Decompress.c. This function is responsible for reading Huffman code lengths from the compressed bitstream and storing them in the mCLen and mPTLen arrays. These arrays are members of the SCRATCH_DATA structure, which is allocated on the heap during initialization.

The mCLen array has a fixed capacity defined by the constant NC (typically 510). However, the ReadCLen function reads a user-controlled 16-bit integer, Number, directly from the bitstream using GetBits(Sd, CBIT). The function then enters a while loop that increments an Index variable up to the value of Number, writing extracted code lengths to Sd->mCLen[Index].

Because there is no boundary check ensuring that Number does not exceed NC, an attacker can specify an arbitrarily large value. This forces the loop to write data beyond the bounds of the mCLen array, corrupting adjacent heap memory. The issue is exacerbated by the Run-Length Encoding (RLE) logic within the loop, which further increments the Index variable without verification.

The vulnerable implementation of ReadCLen allowed the Index variable to increment strictly based on the attacker-controlled Number variable. The snippet below highlights the lack of boundary enforcement within the RLE block.

Number = (UINT16) GetBits (Sd, CBIT);
Index = 0;
while (Index < Number) { 
    CharC = Sd->mPTTable[Sd->mBitBuf >> (BITBUFSIZ - 8)];
    // ... 
    if (CharC == 2) { 
        CharC = (UINT16) GetBits (Sd, 2);
        CharC++;
        while ((INT16) (CharC) >= 0) {
            Sd->mCLen[Index++] = 0; // VULNERABLE: OOB write
            CharC--;
        }
    }
}

The fix, introduced in pull request #145 (commit bf3dfaa8a05675bae6ea0cbfa082ddcebfcde23e), enforces strict boundary limits on all array accesses. The patch modifies the loop conditions to verify Index < NC and Index < NPT before proceeding with memory operations.

Number = (UINT16) GetBits (Sd, CBIT);
Index = 0;
while (Index < Number && Index < NC) { // PATCHED: Check against NC
    CharC = Sd->mPTTable[Sd->mBitBuf >> (BITBUFSIZ - 8)];
    // ... 
    if (CharC == 2) { 
        CharC = (UINT16) GetBits (Sd, 2);
        CharC++;
        while ((INT16) (CharC) >= 0 && Index < NC) { // PATCHED: Check against NC
            Sd->mCLen[Index++] = 0; 
            CharC--;
        }
    }
}

In addition to these bounds checks, the patch includes comprehensive state hardening ported from EDK2. The SCRATCH_DATA struct members were converted from platform-dependent size_t to explicit UINT32 to prevent integer overflow vulnerabilities during bit-buffer arithmetic. Furthermore, the FillBuf function was updated to cast mBitBuf to UINT64 prior to a 32-bit shift, resolving a critical Undefined Behavior (UB) condition.

Exploiting this vulnerability requires the attacker to construct a malformed compressed EFI payload. The payload must define an initial bitstream that passes early decompressor validation but supplies a manipulated Number value when parsed by the ReadCLen function.

When the decompressor executes the malformed bitstream, the ReadCLen function extracts the oversized Number parameter. As the RLE decompression loop executes, it writes zeros (or specific extracted lengths) into heap addresses continuously past the mCLen array boundaries. This sequential overwrite allows the attacker to corrupt adjacent internal structures or other heap allocations within the Python process executing the library.

To achieve reliable arbitrary code execution, the attacker must align the target SCRATCH_DATA allocation on the heap such that critical pointers or object metadata reside immediately adjacent to the mCLen buffer. Overwriting function pointers or Python object headers can hijack the execution flow. If the allocation is not perfectly aligned, the overwrite will corrupt heap metadata, resulting in an immediate segmentation fault and a denial of service.

This vulnerability yields a maximum CVSS v3.1 score of 9.8, indicating critical severity. The attack vector is classified as Network (AV:N) because the vulnerable library is commonly used in backend pipelines, automated analysis systems, and CI/CD environments that ingest external firmware files for automated processing.

The requirement for user interaction is None (UI:N), and no specific privileges are required (PR:N). When a vulnerable pipeline processes an uploaded firmware image containing the malicious bitstream, the exploit triggers automatically during the decompression phase. The flaw affects both the confidentiality, integrity, and availability metrics (C:H/I:H/A:H) as memory corruption provides a pathway to arbitrary code execution within the context of the host process.

Successful code execution enables an attacker to compromise the analysis environment, extract sensitive firmware decryption keys from memory, pivot to internal networks, or modify analysis results. Even in scenarios where heap layouts prevent reliable code execution, the resulting segmentation fault causes persistent denial of service conditions, crashing automated firmware extraction pipelines.

The primary remediation for this vulnerability is to upgrade the uefi-firmware-parser library to version 1.13 or later. The patch completely resolves the out-of-bounds write by applying correct boundary limits during the parsing of compressed length values and synchronizing the internal state mechanics with modern EDK2 hardening standards.

For systems utilizing the Python Package Index (PyPI) distribution, the upgrade should be executed via standard package management commands. Administrators must ensure that all virtual environments and container images executing firmware analysis pipelines are rebuilt to include the updated dependency.

There are no known configuration workarounds to disable the native Tiano decompression extension without breaking core library functionality. If immediate patching is not possible, security teams should implement strict ingress filtering to reject compressed EFI payloads from untrusted sources, or execute the firmware parser strictly within highly isolated, ephemeral sandboxes to contain potential execution.