Gzip decompression bomb in RA-TLS cert extension

[pbeza]

The HTTP client in dstack/dstack-util/src/http_client.rs decompresses gzip-encoded responses without limiting the decompressed output size, so a malicious server can send a small compressed payload that expands to gigabytes in memory.

Root Cause

When parsing RA-TLS certificate extensions, the library decompresses gzip-compressed data without any size limit. A malicious certificate can include a compressed extension that decompresses to an extremely large size (gzip bomb), causing memory exhaustion.

// cert.rs:517-534
let mut decoder = GzDecoder::new(&extension_data[..]);
let mut decompressed = Vec::new();
decoder.read_to_end(&mut decompressed)?;  // No size limit

Attack Path

1. Attacker crafts an X.509 certificate with a gzip-compressed extension containing a decompression bomb
2. The compressed data is small (e.g., 1 KB) but decompresses to gigabytes
3. When a verifier parses the certificate, read_to_end allocates unbounded memory
4. The verifier process crashes due to OOM

Impact

Denial of service against any service that verifies RA-TLS certificates. A single malicious certificate can crash the verifier. The attacker needs to be able to present a certificate for verification (e.g., during mTLS handshake or gateway registration).

Suggested Fix

Limit decompression size. Read one byte beyond the limit to distinguish truncation from exact-size data:

let mut decoder = GzDecoder::new(&extension_data[..]);
let mut decompressed = Vec::new();
let max_size: u64 = 1024 * 1024; // 1 MB limit
decoder.take(max_size + 1).read_to_end(&mut decompressed)?;
if decompressed.len() as u64 > max_size {
    return Err(Error::ExtensionTooLarge);
}

---

Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.

[kvinwang]

Thanks a lot for the detailed report and threat model.

We have implemented a mitigation in #595 that bounds gzip decompression for RA-TLS certificate extensions. Specifically, we:

• Introduce a MAX_EVENTLOG_EXT_SIZE limit (16 KiB) for the event-log extension.
• Wrap the GzDecoder in std::io::Read::take(...) and return an error if the decompressed size exceeds this limit.
• Preserve backwards compatibility with the legacy uncompressed-extension format.

In practice, the event logs we embed in RA-TLS certs today are well below this size, so the 16 KiB cap prevents the unbounded allocation you described without impacting current use cases. If we ever need to carry significantly larger logs, we can revisit the limit or make it configurable.

Really appreciate you taking the time to surface this and write it up so clearly.