Klever-Go MultiDataInterceptor Remote OOM via Compressed Payload
Klever-Go's MultiDataInterceptor is vulnerable to a remote denial-of-service (DoS) attack. By sending a crafted compressed P2P payload, an unauthenticated attacker can trigger excessive memory allocation on the receiving node, leading to an out-of-memory (OOM) condition and potentially disrupting chain liveness.
Klever-Go’s MultiDataInterceptor is vulnerable to a denial-of-service attack stemming from uncontrolled decompression within the Batch.Decompress function. This flaw allows any peer on a topic served by MultiDataInterceptor to trigger multi-gigabyte heap allocations on the receiving node through a sub-50 KiB gossip payload. A single malicious packet can OOM-kill a validator with standard memory provisioning, potentially halting chain liveness. Discovered during an internal security review, the vulnerability affects core/process/interceptors/multiDataInterceptor.go at commit 405d01b0abbf0d3e73b4a990bd7394a01f200dc2. It’s distinct from the GHSA-74m6-4hjp-7226 throttler-slot-leak issue but resides in adjacent code within the same call path. The attack leverages the lack of size validation during decompression, enabling attackers to send small, compressed payloads that expand into enormous data structures in memory.
Attack Chain
- Attacker crafts a malicious compressed payload. This payload is designed to decompress into an extremely large data structure, such as a
Batchcontaining millions of entries. - The malicious payload is sent to a Klever-Go node participating in a topic served by
MultiDataInterceptor. - The
MultiDataInterceptor.ProcessReceivedMessagefunction receives the gossip message. - Within
ProcessReceivedMessage, theb.Decompressfunction is called on the received batch data, as theIsCompressedflag is set. Batch.DecompresscallsdecompressGzipwhich usesio.ReadAllwithout any size limits, leading to an unbounded memory allocation based on the compressed data.- After successful decompression,
Decompressattempts to unmarshal the inflated bytes back into aBatchstructure, again without any size constraints. - The attacker-controlled
DataSizefield is not validated, allowing a small compressed packet to expand into a huge memory allocation. - The memory allocation leads to an out-of-memory (OOM) condition, crashing the Klever-Go node and disrupting chain liveness.
Impact
Successful exploitation of this vulnerability results in a denial-of-service condition on Klever-Go nodes. A single, crafted packet is sufficient to exhaust the memory resources of a validator, leading to its crash. This can impact chain liveness and availability, potentially affecting the entire network if multiple validators are targeted. The low payload size coupled with high amplification makes it easy for attackers to disrupt Klever-Go networks.
Recommendation
- Apply the patch that remediates the vulnerability in
data/batch/batch.goandcore/process/interceptors/multiDataInterceptor.goas outlined in GHSA-87m7-qffr-542v. - Monitor network traffic for abnormally large compressed payloads being sent to Klever-Go nodes using the rules provided below.
- Implement rate limiting and size validation on incoming gossip messages to mitigate the impact of similar decompression-based attacks.
Detection coverage 2
Detect Klever-Go Excessive GZIP Decompression Attempt
highDetects potential attempts to exploit the Klever-Go GZIP decompression vulnerability by monitoring for process creation that might indicate a system crash related to excessive memory allocation, for example by looking for log messages indicating an OOM condition.
Detect Klever-Go Decompression Bomb Network Traffic
mediumDetects potentially malicious network traffic to Klever-Go nodes with abnormally high compression ratios, indicative of a decompression bomb attack
Detection queries are available on the platform. Get full rules →