✓ProveIt
Examples / Report #2905552 Saved analysis

bypass of this Fixed #2437131 [ Inadequate Protocol Restriction Enforcement in curl ]

curl · 2024-12-1813.9s analysis · $0.010 in model calls

What the report claims

The --proto option's protocol restrictions can be bypassed, allowing HTTP requests despite explicit disabling of all protocols.

Compare with curl's recorded outcome

Labeled AI slop

curl's maintainer lists this report as AI slop

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

ProveIt's finding

Needs a policy review

The code does what the report says, but curl's own policy may exclude it. A maintainer decides.

curl policy: Tricking a user to run a command line
Judgment withdrawn. The answer failed the evidence check.
See the withdrawn model reasoning

The following reasoning failed the citation check and does not support the final finding.

  • The report's own reproduction steps show two independent curl invocations, not a bypass within a single invocation.
  • The first command correctly blocks HTTP when --proto disables it.
  • The second command succeeds because it explicitly uses '--proto http' to allow HTTP.
  • No code path is shown where an attacker-controlled input evades the --proto restriction of the same command.
  • The project policy lists 'Tricking a user to run a command line' as not a security issue.
How this analysis ran 5 claims · 0 citations verified

Evidence check: the behavior is real; the project's policy section 'Tricking a user to run a command line' may exclude it

Checked against curl master on 2024-12-18 (c5052a01874b). 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
nothing to check
no model · 0 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
5 claims · 1483 tokens · $0.0002
3 · Evidence
0 code snippets
real curl source at c5052a01874b
4 · Judgment
Nemotron-3-Ultra-550b-a55b
5177 tokens · 10.9s · $0.0094
5 · Receipts
0 of 5 citations verified
every citation must point at code the judge was shown
Inspect the withdrawn draft reply

This draft belongs to the withdrawn judgment. It may contain unsupported claims.

The reproduction steps show two separate curl commands. The first ('--proto -all,-http') correctly blocks HTTP. The second ('--proto http') explicitly allows HTTP in a new, independent invocation. This is expected behavior: each curl command evaluates its own --proto option. No bypass of a single command's restrictions is demonstrated. If you believe a single invocation can evade its own --proto setting, please provide a single command line that does so.

Inspect all claims and source code 5 claims · 0 code excerpts

This model judgment was withdrawn. The claim assessments below are preserved for inspection and may be wrong.

Report claims

C1flaw contradicted

The --proto option can be bypassed to allow unintended protocols

Read the reasoning

The report claims a bypass of protocol restrictions, but the described behavior shows two independent curl commands. The first correctly enforces the restriction (HTTP disabled). The second explicitly requests HTTP and gets it. No single invocation bypasses its own --proto setting.

report:15
C2location contradicted

The bypass occurs in the protocol restriction enforcement logic

Read the reasoning

No bypass within a single invocation is demonstrated. The enforcement logic appears to work as designed: each curl command evaluates its own --proto argument independently.

report:15
C3trigger contradicted

Using --proto -all,-http or --proto =all to attempt to disable HTTP

Read the reasoning

The trigger commands are misunderstood by the reporter. '--proto =all' enables all protocols including HTTP; '--proto -all,-http' disables all then redundantly disables HTTP. The first command in the reproduction fails as expected when HTTP is disabled.

report:11
C4impact contradicted

HTTP requests can be made over plaintext despite restrictions

Read the reasoning

HTTP requests succeed only when the current invocation's --proto option allows HTTP. The 'initial restrictions' applied only to the first invocation. This is expected behavior, not a flaw.

report:15
C5reproduction contradicted

Reproduce by running curl --proto -all,-http http://example.com and observing the error, then curl --proto http http://evil.com to bypass

Read the reasoning

The reproduction steps do not demonstrate a bypass. They demonstrate that each curl command independently evaluates its --proto argument. The second command works because it requests HTTP, not because it evades a prior restriction.

report:20
Read the original report (excerpt)

Full report on HackerOne ↗

## Summary: A flaw has been identified in the curl command-line tool related to its protocol selection mechanism. Specifically, the protocol restrictions set by the --proto option can be bypassed, allowing unintended protocols to be used despite explicit restrictions. This flaw can result in plaintext communication being used even when the user has attempted to disable all protocols except encrypted ones. ##Vulnerability Details Command Triggering the Issue: curl --proto -all,-http http://example.com ##Observed Behavior: The command was intended to disable all protocols and then explicitly disable HTTP. However, the actual behavior allowed HTTP requests to be made, indicating that the protocol restrictions were not enforced correctly. ##Bypass Example: ``` curl --proto =all http://example.com curl --proto http http://evil.com ``` The command curl --proto =all appears to override the protocol restrictions, allowing HTTP requests to bypass the intended restrictions. ##Steps to Reproduce Execute Command with Protocol Disabling: ```curl --proto -all,-http http://example.com``` Observe Error Message: Error: curl: (1) Protocol "http" disabled Execute Bypass Command: ` curl --proto http http://evil.com` Observe Successful Request: The request is made over HTTP despite the initial restrictions. ##Potential Risks Security Breach: Users may believe they have enforced secure communication protocols, but the flaw could result in unencrypted communication, increasing the risk of eavesdropping or man-in-the-middle attacks. User Trust: Users trusting curl for secure communication may be misled by incorrect protocol enforcement. ##Mitigation Update curl: Ensure that you are using the latest version of curl, as this issue might be addressed in newer releases. Use Explicit Protocols: Instead of disabling protocols, explicitly specify the protocols you want to allow: ` curl --proto https https://example.com` ##Recommendation Report to Maintainters: Consider reporting this issue to the curl maintainers if it has not been already reported. Provide them with detailed reproduction steps and observed behavior. ## Impact ## Summary: Unencrypted Communication: The flaw allows requests to be made over unencrypted protocols (such as HTTP) even when the user has explicitly disabled plaintext protocols. Data Exposure Risk: This can …

Source code

No source code was retrieved for this analysis. The evidence may be incomplete.