Listen to this Post
The vulnerability resides in the Tiano/EFI decompressor used by the uefi-firmware project, specifically in the `ReadCLen()` function within Decompress.c. The function calls `GetBits(Sd, CBIT)` where `CBIT` is hardcoded to 9, returning a value `Number` between 0 and 511 inclusive. This `Number` is then used as an upper bound for a loop that writes into the array Sd->mCLen, which has a fixed size `NC = 510` elements. The loop condition `Index < Number` lacks any check against NC, allowing `Index` to reach up to 511, which writes 1 element past the buffer (indices 0..511 vs allocated 0..509). Additionally, when the decompressor encounters a run-length encoded symbol (CharC == 2), it performs GetBits(Sd, 9) + 20, yielding up to 531. The subsequent loop writes zeros via Sd->mCLen[Index++] = 0, again without bounds checking, causing up to 21 extra zero writes beyond the 510‑element boundary (indices 510..530). The entire parsing path is reachable via: `CompressedSection.process()` → `efi_compressor.TianoDecompress()` → `TianoDecompress()` → `DecodeC()` → ReadCLen(). This heap out‑of‑bounds write occurs during firmware image parsing, typically when a compressed EFI section is processed. The minimum impact is a deterministic crash due to heap metadata corruption. Depending on heap layout, compiler optimizations, and platform specifics, the corruption can be leveraged for arbitrary code execution within the context of the parsing process. The project shipped its own copy of the decompressor without the upstream EDK2 hardening patches that address this class of bugs.
dailycve form:
Platform: UEFI firmware
Version: uefi-firmware (unspecified)
Vulnerability: Heap OOB write
Severity: Critical
date: Unspecified in
Prediction: Patch within 30 days
Analytics under heading What Undercode Say:
Check for vulnerable Decompress.c in firmware repo
grep -n "CBIT = 9" uefi_firmware/compression/Tiano/Decompress.c
Verify missing bounds check in ReadCLen()
awk '/ReadCLen/,/}/' uefi_firmware/compression/Tiano/Decompress.c | grep -E "while.Index < Number"
Count mCLen array size (NC)
grep -n "define NC" uefi_firmware/compression/Tiano/Decompress.c
Simulate overflow with fuzzing input
python3 -c "print('\x00'512)" > crash.bin
Monitor heap corruption using valgrind
valgrind --tool=memcheck ./firmware_parser crash.bin
Exploit:
Craft a malicious compressed EFI section where the Huffman code length table triggers `Number = 511` or a run-length of 531. The loop writes beyond `mCLen` into adjacent heap structures (e.g., free list pointers or function pointers). By controlling the overwritten data, an attacker can hijack control flow when the decompressor later uses corrupted metadata or calls a function pointer. Exploit reliability depends on heap layout and mitigation (ASLR, heap hardening).
Protection from this CVE:
- Apply upstream EDK2 patches that add `Index < NC` checks in `ReadCLen()` and limit run-length writes.
- Replace the vulnerable decompressor with the latest EDK2 reference implementation.
- Enable heap hardening flags (e.g.,
-D_FORTIFY_SOURCE=2,-Wp,-D_GLIBCXX_ASSERTIONS). - Use static analysis tools (Coverity, Clang Static Analyzer) to catch out‑of‑bounds writes.
- Isolate firmware parsing in a sandboxed process with minimal privileges.
Impact:
Deterministic crash (denial of service) in all affected builds. Potential arbitrary code execution with the same privileges as the firmware parser – often within the UEFI DXE phase or OS‑level firmware update tool, leading to persistent compromise, bypass of secure boot, or system takeover.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
