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.