CVE-2024-24791: net/http HTTP/1.1 Client DoS Vulnerability

CVE-2024-24791 Overview

CVE-2024-24791 is a denial of service vulnerability in Go's net/http HTTP/1.1 client that affects how the client handles server responses to requests containing the Expect: 100-continue header. When a server responds with a non-informational status code (200 or higher) instead of the expected 100 Continue response, the client mishandles this scenario, leaving the connection in an invalid state. Subsequent requests on the affected connection will fail, enabling attackers to disrupt service availability.

Critical Impact

Attackers can exploit this vulnerability to cause denial of service against applications using Go's net/http/httputil.ReverseProxy by sending crafted requests that trigger connection invalidation, causing cascading failures for legitimate traffic.

Affected Products

• Go net/http package (HTTP/1.1 client)
• Go net/http/httputil.ReverseProxy
• Applications and services built with affected Go versions

Discovery Timeline

• 2024-07-02 - CVE-2024-24791 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2024-24791

Vulnerability Analysis

The vulnerability exists in Go's net/http HTTP/1.1 client implementation, specifically in how it processes server responses to requests that include the Expect: 100-continue header. The HTTP/1.1 protocol defines that when a client sends a request with this header, the server should respond with a 100 Continue informational response before the client sends the request body, or respond with a final status code to reject the request early.

Go's HTTP client implementation fails to properly handle the case where a server responds with a non-informational status code (200 or higher) to such requests. This mishandling corrupts the internal state of the HTTP connection, making it invalid for subsequent use. When the connection is reused for another request, that request will fail due to the corrupted connection state.

This vulnerability is particularly impactful when exploited against net/http/httputil.ReverseProxy, a commonly used component for building API gateways, load balancers, and reverse proxy servers. An attacker can repeatedly send requests with Expect: 100-continue headers, and if the backend server responds with non-informational status codes, each such request poisons one connection in the proxy's connection pool.

Root Cause

The root cause lies in improper state management within the HTTP/1.1 client's connection handling logic. When the client sends a request with an Expect: 100-continue header, it enters a state waiting for either a 100 Continue response or a final response. However, when the server sends a non-informational response directly, the client's internal state machine fails to properly reset the connection state, leaving residual state that interferes with subsequent request processing on the same connection.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Identifying a target application using Go's ReverseProxy or similar HTTP client functionality
2. Sending HTTP requests with the Expect: 100-continue header to the proxy
3. Ensuring the backend server responds with a non-informational status code (e.g., 200, 400, 500)
4. Each successful exploitation corrupts one connection, causing the next legitimate request on that connection to fail

The attack can be sustained to continuously degrade service availability by systematically poisoning connections in the proxy's connection pool.

Detection Methods for CVE-2024-24791

Indicators of Compromise

• Unusual volume of HTTP requests containing Expect: 100-continue headers from single sources
• Increased connection errors or request failures on reverse proxy servers
• Pattern of connections being prematurely terminated or reset after specific requests
• Backend server logs showing non-informational responses to requests with Expect headers

Detection Strategies

• Monitor HTTP traffic for abnormal patterns of Expect: 100-continue headers, particularly from untrusted sources
• Implement logging and alerting for sudden increases in HTTP client connection errors
• Analyze reverse proxy logs for correlation between Expect header requests and subsequent connection failures
• Deploy network intrusion detection rules to flag suspicious Expect header patterns targeting proxy endpoints

Monitoring Recommendations

• Enable detailed logging on Go-based HTTP proxies to capture header information and connection lifecycle events
• Set up metrics collection for connection pool health, tracking invalidation rates and error frequencies
• Implement baseline monitoring for normal Expect: 100-continue usage patterns to detect anomalies
• Configure alerts for elevated rates of HTTP 5xx errors following patterns of Expect header requests

How to Mitigate CVE-2024-24791

Immediate Actions Required

• Upgrade Go to a patched version that addresses the net/http client connection handling issue
• Review applications using net/http/httputil.ReverseProxy for exposure to untrusted traffic
• Consider implementing rate limiting on incoming requests with Expect: 100-continue headers
• Monitor for exploitation attempts while planning upgrade rollouts

Patch Information

The Go development team has addressed this vulnerability through code changes to the net/http package. Technical details of the fix can be found in the Go.dev Code Change. The vulnerability is tracked in the Go.dev Issue Tracker and documented in the Go.dev Vulnerability Report.

Organizations using NetApp products should also review the NetApp Security Advisory for product-specific guidance.

Workarounds

• Deploy a web application firewall (WAF) or reverse proxy in front of vulnerable Go applications to filter or rate-limit requests with Expect: 100-continue headers
• Configure backend servers to always respond with 100 Continue to requests with this header when appropriate, reducing the likelihood of triggering the vulnerable code path
• Implement connection health checks and aggressive connection recycling to limit the impact of poisoned connections
• Consider disabling HTTP/1.1 connection keep-alive for high-risk endpoints as a temporary measure to prevent connection reuse

# Example: Rate limiting Expect header requests using nginx
# Add to nginx configuration for proxied endpoints
limit_req_zone $binary_remote_addr zone=expect_limit:10m rate=10r/s;

location /api/ {
    # Limit requests with Expect headers
    if ($http_expect ~* "100-continue") {
        set $limit_key $binary_remote_addr;
    }
    limit_req zone=expect_limit burst=5 nodelay;
    proxy_pass http://go_backend;
}