SSH Connection Reuse Authentication-Context Bypass
SSH connection reuse matching in libcurl does not verify SSH authentication context.
- Vendor
- curl
- Product
- libcurl
- Affected
- <= master (prior to fix)
Executive Summary
SSH connection reuse matching in libcurl does not verify SSH authentication context (selected private/public key files). A request can reuse an existing authenticated SSH channel established with different SSH key settings, causing operations to execute under an unintended SSH identity.
Affected Versions
- libcurl with SSH/SFTP support (libssh2 and libssh backends)
Details
The reuse flow (Curl_connect -> url_find_or_create_conn -> url_attach_existing -> Curl_cpool_find -> url_match_conn) calls url_match_proto_config at lib/url.c:918, which only checks HTTP/FTP-specific protocol config and has no SSH-equivalence checks.
SSH key identity is loaded later from per-request options in lib/vssh/libssh2.c (ssh_state_pkey_init) and lib/vssh/libssh.c (myssh_in_AUTH_PKEY_INIT). Reused connections skip protocol connect/auth in lib/multi.c:2523-2529, so authentication is never re-evaluated for the new request context.
An application performing back-to-back SSH/SFTP requests with different CURLOPT_SSH_PRIVATE_KEYFILE / CURLOPT_SSH_PUBLIC_KEYFILE settings to the same destination will have the second request silently reuse the first connection's SSH identity.
Impact
Cross-request authentication-context confusion. Operations can execute under a prior SSH identity rather than the intended one, potentially granting unauthorized access to resources.