✓ProveIt
Examples / Report #2829063 Saved analysis

CVE-2024-11053: netrc + redirect credential leak

curl · 2024-11-0811.6s analysis · $0.008 in model calls

What the report claims

Curl leaks credentials from netrc to redirect targets when parsing netrc during redirects, causing unexpected credential exposure.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2024-11053 netrc and redirect credential leak

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 report describes a concrete, plausible credential leak scenario with a specific netrc file format and reproduction steps.
  • The provided source code (lib/urldata.h) contains only type definitions and does not include the netrc parsing implementation (likely in lib/netrc.c) or the redirect credential handling logic.
  • Deterministic checks returned 'nothing_to_check', confirming the relevant code was not in the provided context.
  • Without the actual netrc and redirect handling code, the claims cannot be verified or contradicted.
What still needs checking
  • Source code for netrc parsing (likely lib/netrc.c)
  • Source code for credential handling during HTTP redirects (likely in lib/http.c or lib/url.c)
  • The Curl_easy/connectdata structures showing how user/password are stored and updated during redirects
How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2024-11-08 (1f6767e7a001). 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 · 1277 tokens · $0.0002
3 · Evidence
1 code snippets
real curl source at 1f6767e7a001
4 · Judgment
Nemotron-3-Ultra-550b-a55b
5392 tokens · 9.3s · $0.0083
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 detailed report. The provided code snippet (lib/urldata.h) does not contain the netrc parsing or redirect credential logic needed to evaluate this claim. Could you point to the specific files/functions where netrc credentials are read and applied during redirects (e.g., lib/netrc.c, the redirect handling in lib/http.c or lib/url.c)? With those sources we can verify whether a match on the redirect target incorrectly retains the prior password.

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

Report claims

C1flaw not verifiable

curl passes along credentials specified for the original host to the redirection target under certain conditions

Read the reasoning

The claim describes a flaw in netrc credential handling during redirects. The provided source code (lib/urldata.h) only contains type definitions and does not include the netrc parsing logic or redirect handling code that would confirm or contradict this claim.

C2location not verifiable

when parsing netrc file during redirect

Read the reasoning

The claim locates the issue in 'parsing netrc file during redirect.' The provided source does not contain the netrc parsing implementation or the redirect credential logic.

C3trigger not verifiable

if a match is found clear the previous username and password

Read the reasoning

The claim states a suggested remediation about clearing username/password when a netrc match is found during redirect. The relevant credential management code during redirects is not in the provided source.

C4impact not verifiable

unexpected leak of credentials

Read the reasoning

The impact claim of 'unexpected leak of credentials' depends on the behavior described in C1-C3, which cannot be verified from the provided code.

C5reproduction not verifiable

Credentials bob:alicespassword will be sent to https://b

Read the reasoning

The specific reproduction scenario (credentials 'bob:alicespassword' sent to https://b) requires the netrc parsing and redirect credential selection logic, which is not present in the provided source file.

Read the original report

Full report on HackerOne ↗

## Summary: Curl has a logic flaw in the way it processes netrc credentials when performing redirects. The redirect will pass along credentials specified for the original host to the redirection target under certain conditions, resulting in unexpected leak of credentials to the redirect target. ## Steps To Reproduce: 1. Have two sites `https://a` and `https://b`. `https://a` does 301 redirect to `https://b` 2. Have netrc file with the following: ``` machine a login alice password alicespassword default login bob ``` 3. `curl -L --netrc-file netrc -v https://a` Credentials `bob:alicespassword` will be sent to `https://b`. ## Suggested remediation When parsing netrc file during redirect, if a match is found clear the previous username and password. ## Note This flaw manifests itself if the netrc file matches the redirect target, but the entry omits password or both login & password. ## Impact Unexpected leak of credentials. If the login is specified for the redirect target host in netrc, only the password is leaked, if neither login or password is specified full credentials are leaked.

Source code

lib/urldata.hlines 184–259 · definition of CURLcode
184typedef CURLcode (*Curl_datastream)(struct Curl_easy *data,
185 struct connectdata *conn,
186 int *didwhat,
187 int select_res);
188#endif
189
190#include "mime.h"
191#include "imap.h"
192#include "pop3.h"
193#include "smtp.h"
194#include "ftp.h"
195#include "file.h"
196#include "vssh/ssh.h"
197#include "http.h"
198#include "rtsp.h"
199#include "smb.h"
200#include "mqtt.h"
201#include "ftplistparser.h"
202#include "multihandle.h"
203#include "c-hyper.h"
204#include "cf-socket.h"
205
206#ifdef HAVE_GSSAPI
207# ifdef HAVE_GSSGNU
208# include <gss.h>
209# elif defined HAVE_GSSAPI_GSSAPI_H
210# include <gssapi/gssapi.h>
211# else
212# include <gssapi.h>
213# endif
214# ifdef HAVE_GSSAPI_GSSAPI_GENERIC_H
215# include <gssapi/gssapi_generic.h>
216# endif
217#endif
218
219#ifdef USE_LIBSSH2
220#include <libssh2.h>
221#include <libssh2_sftp.h>
222#endif /* USE_LIBSSH2 */
223
224#define READBUFFER_SIZE CURL_MAX_WRITE_SIZE
225#define READBUFFER_MAX CURL_MAX_READ_SIZE
226#define READBUFFER_MIN 1024
227
228/* The default upload buffer size, should not be smaller than
229 CURL_MAX_WRITE_SIZE, as it needs to hold a full buffer as could be sent in
230 a write callback.
231
232 The size was 16KB for many years but was bumped to 64KB because it makes
233 libcurl able to do significantly faster uploads in some circumstances. Even
234 larger buffers can help further, but this is deemed a fair memory/speed
235 compromise. */
236#define UPLOADBUFFER_DEFAULT 65536
237#define UPLOADBUFFER_MAX (2*1024*1024)
238#define UPLOADBUFFER_MIN CURL_MAX_WRITE_SIZE
239
240#define CURLEASY_MAGIC_NUMBER 0xc0dedbadU
241#ifdef DEBUGBUILD
242/* On a debug build, we want to fail hard on easy handles that
243 * are not NULL, but no longer have the MAGIC touch. This gives
244 * us early warning on things only discovered by valgrind otherwise. */
245#define GOOD_EASY_HANDLE(x) \
246 (((x) && ((x)->magic == CURLEASY_MAGIC_NUMBER))? TRUE: \
247 (DEBUGASSERT(!(x)), FALSE))
248#else
249#define GOOD_EASY_HANDLE(x) \
250 ((x) && ((x)->magic == CURLEASY_MAGIC_NUMBER))
251#endif
252
253#ifdef HAVE_GSSAPI
254/* Types needed for krb5-ftp connections */
255struct krb5buffer {
256 struct dynbuf buf;
257 size_t index;
258 BIT(eof_flag);
259};