Listen to this Post
The vulnerability in the ulikunitz/xz LZMA decoder arises from its handling of a malformed archive header. The LZMA format specification does not mandate a magic number or checksum in its header, making it susceptible to prefix data injection. An attacker can prepend a single zero byte to a valid LZMA stream. The decoder reads the header fields (dictionary size, uncompressed size) from this manipulated stream without initial validation. It immediately allocates a decoding buffer based on the enormous dictionary size value parsed from the malicious header, which is interpreted as a 64-bit integer. This leads to a massive, uncontrolled memory allocation (e.g., several gigabytes), exhausting system RAM. The decoder only identifies the stream as invalid later during the actual decompression phase, after the harmful allocation has already occurred, causing denial-of-service through resource exhaustion.
Platform: Go module
Version: <0.5.14
Vulnerability: Memory exhaustion
Severity: Critical
date: 2024
Prediction: 2024-10-15
What Undercode Say:
Identify affected module versions in your project golangci-lint run --enable=go-modirectives Check for known vulnerabilities in dependencies govulncheck -test ./... Example of a malicious file creation for testing (PoC) echo -ne '\x00' | cat - valid_archive.lzma > malicious.lzma
// Safe reading with a configured dictionary cap
config := lzma.ReaderConfig{
DictCap: 1 << 30, // Limit to 1GB
}
r, err := config.NewReader(originalReader)
How Exploit:
Prepend zero byte to LZMA archive. Server allocates massive memory upon `lzma.NewReader` call, causing instant OOM crash.
Protection from this CVE
Update to v0.5.14. Set ReaderConfig.DictCap. Validate untrusted archives pre-decompression.
Impact:
Critical memory exhaustion. Immediate denial-of-service for services unpacking user-supplied LZMA files.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
