Kerberos/SPNEGO Connection Reuse Vulnerability

# Kerberos/SPNEGO Connection Reuse Vulnerability in curl ## Summary curl reuses HTTP connections across different users without checking Kerberos state. User B's request can inherit User A's GSS security context, allowing authentication bypass. ## Affected Versions All curl versions with Kerberos support (tested and confirmed on curl 8.5.0) ## Root Cause `ConnectionExists()` in `lib/url.c` checks NTLM state (lines 1214-1273) but has no equivalent check for `http_negotiate_state` or `proxy_negotiate_state`. When Kerberos auth completes, `conn->http_negotiate_state` advances to `GSS_AUTHSUCC` and the GSS security context remains valid. Since `hashkey()` (`lib/conncache.c:126-150`) only uses `port+hostname` (no credentials) and HTTP sets `PROTOPT_CREDSPERREQUEST` which skips credential checks, any request to the same `host:port` reuses the connection with the previous user's GSS context. ## Partial Mitigation curl has `noauthpersist` (`lib/http_negotiate.c:140-152`) that cleans up GSS context for single-roundtrip Negotiate (MIT Kerberos). However: - When `havemultiplerequests` is TRUE (multi-roundtrip auth, common with Windows AD/IIS), `noauthpersist` is FALSE and no cleanup occurs - This cleanup happens AFTER `ConnectionExists()` already matched the connection - wrong defensive layer - NTLM has protection in both layers; Negotiate has neither ## Suggested Fix Add `#if defined(USE_SPNEGO)` block to `ConnectionExists()` mirroring the NTLM pattern: - Compare credentials when Negotiate is wanted - Reject connections with active Negotiate state if new request doesn't want it - Add per-transfer Negotiate state reset (like NTLM at `url.c:3776-3792`) **Note:** For SSO (`--negotiate -u :`), usernames are empty so credential comparison won't work - might need to clear GSS context unconditionally or force separate connections. Apply to both `http_negotiate_state` and `proxy_negotiate_state`. ## Proof of Concept I've developed a complete reproduction package with real Kerberos authentication: ### Files Included: 1. **source-analysis.md** - Detailed code analysis with line numbers and exploitation flow 2. **run-exploit.sh** - Automated PoC demonstrating the vulnerability 3. **test-server.py** - GSSAPI test server that tracks GSS context per TCP connection ### Reproduction Steps: 1. Setup Kerberos KDC with test users (alice, bob) 2. Run `./run-exploit.sh` 3. Observe connection reuse and GSS context inheritance The PoC demonstrates: - Alice authenticates with `--negotiate` - Bob makes a request to the same server - Connection is reused (same TCP socket) - Server logs show: `"CONNECTION REUSED - GSS context persists for [email protected]"` ## Technical Details See attached `source-analysis.md` for: - Complete code analysis - Comparison with NTLM protection mechanism - Exploitation flow for different scenarios (single-roundtrip vs multi-roundtrip) - Root cause explanation with exact file/line references ## Attachments - `source-analysis.md` - Technical deep dive - `run-exploit.sh` - Working proof-of-concept - `test-server.py` - Test server for reproduction --- **Reported by:** Ramesh Adhikari ([email protected]) ## Impact ## Impact Corporate environments using Kerberos authentication are at high risk. Attack scenarios include: - **CI/CD pipelines** with multiple service accounts accessing the same API - **Shared web servers** where User B's request executes with User A's privileges - **Multi-tenant applications** where connection pools are shared across users