Skipper: Unbounded Request Body Read in Admission Webhook Causes Memory Exhaustion DoS

Summary

The Kubernetes admission webhook handler reads the entire request body using io.ReadAll(r.Body) without any size limit. Any client that can reach the webhook port within the cluster can send a multi-GB payload, causing the skipper process to exhaust memory and be OOM-killed. This disrupts all Kubernetes admission control, potentially blocking all pod creation and updates.

Vulnerable Code

// dataclients/kubernetes/admission/admission.go:76
body, err := io.ReadAll(r.Body)  // <-- NO SIZE LIMIT
if err != nil {
    log.Errorf("Failed to read request: %v", err)
    w.WriteHeader(http.StatusInternalServerError)
    invalidRequests.WithLabelValues(admitterName).Inc()
    return
}

var review admissionReview
err = json.Unmarshal(body, &review)

For comparison, the OPA filter has a body size limit:

// filters/openpolicyagent/openpolicyagent.go:68-70
const DefaultMaxRequestBodySize = 1 << 20 // 1MB

// OPA uses a bufferedBodyReader with size limits

Attack Path

1. Attacker identifies the admission webhook endpoint (default: :9443/admission or configured path)
2. Attacker sends: POST /admission HTTP/1.1, Content-Type: application/json with a multi-GB request body
3. io.ReadAll(r.Body) allocates unbounded memory for the entire body
4. Skipper process is OOM-killed by the Kubernetes kubelet

Permission Boundary Analysis

• Attacker: Any client with network access to the admission webhook port within the Kubernetes cluster
• Boundary crossed: Memory safety — unbounded allocation from attacker-controlled input
• Preconditions: Admission webhook endpoint must be network-reachable (default Kubernetes deployment exposes it within cluster network)
• Comparison: OPA filter has DefaultMaxRequestBodySize (1MB) and semaphore-based memory limit; admission handler has neither

Evidence

File	Lines	Description