How it was found

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