Envoy is a popular open-source edge and service proxy, often used in cloud-native environments for routing and load balancing. But even great software can have bugs—and sometimes, those bugs can be dangerous. In this post, we’ll break down CVE-2022-29225, a vulnerability in Envoy’s decompression filter, show you how it works, give you sample exploit code, link to official references, and guide you on how to protect yourself.

What Is CVE-2022-29225?

In Envoy versions before 1.22.1, there’s a problem in how the proxy handles decompression of data like zlib or gzip. When decompressing, Envoy collects the decompressed data in a buffer *before* writing it to the HTTP body. But here’s the catch: the buffer grows with the size of the decompressed data, not the original compressed data. That means a tiny, highly-compressed payload can expand massively in memory during decompression.

If an attacker sends a special compressed file called a zip bomb, they can exhaust system memory and crash Envoy, leading to a Denial of Service (DoS).

Why Is This Dangerous?

A zip bomb is a classic trick in cyber security. Imagine a 1KB zip file that, when decompressed, becomes 1GB or more. If a server doesn’t control decompression carefully, attackers can make it run out of memory instantly.

The Vulnerable Code (Explained Simply)

Below is a simplified code snippet showing the buffering problem. Let’s imagine what’s happening inside Envoy’s decompressor filter:

// Simplified pseudocode

void decodeBody(Request& request) {
    Buffer decompressedBuffer;

    // Decompress entire payload at once
    decompressor.decompress(request.body(), decompressedBuffer);

    // Overwrite original body
    request.setBody(decompressedBuffer.data());
}

The bug: decompressedBuffer could get *very* large before it’s written. There’s NO size limit on decompressedBuffer during this process.

How to Exploit: A Basic Example

Let’s see this with an actual compressed zip bomb. You can use tools like zip or online generators to make a zip bomb, but here’s a Python example that creates a highly compressed file:

import zlib

# Construct a simple zip bomb payload: compress 1GB of "A"
payload = b"A" * (1024 * 1024 * 1024)  # 1GB of data
compressed = zlib.compress(payload, level=9)

with open("bomb.zlib", "wb") as f:
    f.write(compressed)

print(f"Compressed size: {len(compressed)} bytes")

Official References

- CVE Details: CVE-2022-29225 detail
- Envoy Security Advisory: GitHub Issue Advisory
- Patch: Fix commit on GitHub

1. Upgrade Envoy

The ONLY real fix is to upgrade to version 1.22.1 or newer, where decompression controls were added.
Recommended Action:

# Update your Envoy installation. For example:
docker pull envoyproxy/envoy:v1.22.1

2. Mitigation: Disable Decompression

If you can’t upgrade right now, turn off decompression in your filter config. Here’s an example of how to remove or disable the decompress filter in your envoy.yaml:

http_filters:
- name: envoy.filters.http.decompressor
  # Remove or comment out this filter!

Conclusion

CVE-2022-29225 is a classic example of how a small bug can turn into a huge problem. If you run Envoy versions before 1.22.1 and use decompression, you’re exposed to zip bomb DoS attacks.

Disable decompression until you can upgrade

Don’t give attackers a “shortcut” to take your service down!


*Stay safe, and for more in-depth technical breakdowns, keep following!*

Timeline

Published on: 06/09/2022 20:15:00 UTC
Last modified on: 06/16/2022 17:30:00 UTC