✓ProveIt
Examples / Report #1898475 Saved analysis

CVE-2023-27538: SSH connection too eager reuse still

curl · 2023-03-0912.7s analysis · $0.009 in model calls

What the report claims

SSH connection reuse check fails because the protocol family comparison uses == instead of &, causing it to never match.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2023-27538 SSH connection too eager reuse still

Shown for comparison after analysis. The pipeline did not see this label.

ProveIt's finding

Needs human review

The available evidence does not settle the report. A maintainer should investigate.

Why this finding?
  • The logical flaw in the comparison (C1-C4) is mathematically proven by the provided constant definitions: PROTO_FAMILY_SSH=48 while get_protocol_family returns only 16 or 32, so == never matches.
  • However, the actual connection reuse code containing this comparison is not provided in the source snippets. The report's central claim that this broken check exists in the SSH connection reuse logic cannot be verified from the given code.
  • Without seeing the usage site, we cannot confirm the bug is reachable or that it causes the claimed impact (connection reuse with different SSH keys).
  • The deterministic checks confirm the symbols exist but not their usage in the connection reuse path.
What still needs checking
  • The source file and next steps: The connection reuse code where `get_protocol_family(needle->handler) == PROTO_FAMILY_SSH` is allegedly used. Likely in lib/url.c or lib/conncache.c around connection matching logic.
How this analysis ran 6 claims · 0 citations verified

Checked against curl master on 2023-03-09 (29a19369ec49). Dev evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.

1 · Grounding
grounded
no model · 4 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
6 claims · 1337 tokens · $0.0002
3 · Evidence
3 code snippets
real curl source at 29a19369ec49
4 · Judgment
Nemotron-3-Ultra-550b-a55b
4504 tokens · 10.2s · $0.0093
5 · Receipts
0 of 0 citations verified
every citation must point at code the judge was shown
Review a draft reply to the reporter

Edit and verify before sending.

Thank you for the report. The bitmask logic flaw you describe (using == instead of &) is mathematically correct based on the constant definitions. However, we need to locate the actual connection reuse code where this comparison occurs to verify the bug is present and reachable. Could you point to the specific file and function where this check lives (e.g., in the connection cache/matching logic)? That will let us confirm the fix applies to the right code path.

Inspect all claims and source code 6 claims · 3 code excerpts

Report claims

C1flaw supported

The check `get_protocol_family(needle->handler) == PROTO_FAMILY_SSH` never matches because the handler family is either CURLPROTO_SCP or CURLPROTO_SFTP.

Read the reasoning

The claim is mathematically correct based on the provided definitions. PROTO_FAMILY_SSH = CURLPROTO_SCP|CURLPROTO_SFTP = (1<<4)|(1<<5) = 16|32 = 48. get_protocol_family returns h->family which is either CURLPROTO_SCP (16) or CURLPROTO_SFTP (32). Neither 16==48 nor 32==48 is true, so the equality check never matches. The evidence is in the constant definitions: lib/urldata.h:102, include/curl/curl.h:1040-1041, and the function return value in lib/url.c:164.

C2flaw supported

The intended check should use a bitwise AND (`&`) instead of equality (`==`) to test for SSH protocol family.

Read the reasoning

The proposed fix using bitwise AND is correct for testing membership in a bitmask. Since PROTO_FAMILY_SSH is a bitmask combining two protocol bits, the proper test is (value & mask) != 0. This follows from the same constant definitions as C1.

C3flaw supported

Using `==` on a bitmask leads to incorrect logic evaluation.

Read the reasoning

This is a correct general observation about the bug pattern. Using == on a bitmask that combines multiple flags will only match if all bits are set simultaneously, which is impossible when the function returns exactly one flag. Supported by the same definitions.

C4flaw supported

The fix changes the comparison to `get_protocol_family(needle->handler) & PROTO_FAMILY_SSH`.

Read the reasoning

This accurately describes the proposed fix. The fix would correctly evaluate to non-zero (true) for both CURLPROTO_SCP (16 & 48 = 16) and CURLPROTO_SFTP (32 & 48 = 32).

C5flaw not verifiable

The report suggests the bug affects SSH connection reuse when different SSH keys are used.

Read the reasoning

The impact claim requires seeing the connection reuse code where this comparison is used, to verify that (a) the comparison exists in that code path, (b) it guards SSH key comparison, and (c) the failure leads to connection reuse with different keys. The provided source snippets only show constant/function definitions, not the usage site in the connection reuse logic.

C6flaw not verifiable

The reproduction involves making two connections to the same host with different SSH keys.

Read the reasoning

Reproduction steps depend on the actual vulnerable code path existing. Without the connection reuse code, cannot verify this would trigger the bug.

Read the original report

Full report on HackerOne ↗

## Summary: There's a check if SSH keys match between new and existing connection when considering reuse. This check is broken due to wrong comparison: `#define PROTO_FAMILY_SSH (CURLPROTO_SCP|CURLPROTO_SFTP)` ... `else if(get_protocol_family(needle->handler) == PROTO_FAMILY_SSH) {` This never matches as handler family is either `CURLPROTO_SCP` or `CURLPROTO_SFTP`. ## Remediation * Make the code: `else if(get_protocol_family(needle->handler) & PROTO_FAMILY_SSH) {` ## Steps To Reproduce: 1. Make two connections to the same host with different ssh keys ## Impact Connection reuse when different ssh keys are used.

Source code

lib/urldata.hlines 102–102 · definition of PROTO_FAMILY_SSH
102#define PROTO_FAMILY_SSH (CURLPROTO_SCP|CURLPROTO_SFTP)
lib/url.clines 160–165 · definition of get_protocol_family
160static curl_prot_t get_protocol_family(const struct Curl_handler *h)
161{
162 DEBUGASSERT(h);
163 DEBUGASSERT(h->family);
164 return h->family;
165}
include/curl/curl.hlines 1040–1041 · definition of CURLPROTO_SCP; definition of CURLPROTO_SFTP
Show 2 lines (not cited by the judge)
1040#define CURLPROTO_SCP (1<<4)
1041#define CURLPROTO_SFTP (1<<5)