libcurl has had auth leak bug since 'the first commit we recorded'

If you use libcurl, the command line tool and library for transferring data with URLs, get ready to patch. The tool has a pair of problems, one of which is an authentication leak. This advisory says the library can leak authentication data to third parties because of how it handles custom headers in HTTP requests. “When asked …

[teknopaul]

location trusted

Ow how much will that break.

If you are sending auth headers the location _is_ trusted. If it redirects to a hackersite that was misplaced trust. But no reason to break the commandline internet.

[PeteA]

Re: location trusted

Indeed. Props to the libcurl team for helping people not to shoot themselves in the foot, but the (previous) behaviour is exactly what I'd expect from the man page:

-L, --location

(HTTP) If the server reports that the requested page has moved to a different location (indicated with a Location: header and a 3XX response code), this option will make curl redo the request on the new place.

Headers are part of an HTTP request, so I'd expect them to be sent to "the new place".

[Anonymous Coward]

Re: location trusted

Indeed, I read this part

Applications that pass on custom authorisation headers could therefore leak credentials or “data that could allow others to impersonate the libcurl-using client's request”.

and thought that as the application writer you should make no assumptions about how well written your client is and therefore this issue is your issue. As you state it is kind of expected behaviour from the client so be careful what you send it.

[frank ly]

There's always something nowadays

I didn't have curl on my Debian 9 (Stretch) installation but I did have libcurl3 v.7.52.1-5. So I installed curl and it was v.7.52.1-5. I'll give it a regular prod with the update stick to see how quickly Debian deal with this.

[Anonymous Coward]

Re: There's always something nowadays

They probably backported the fix. The -5 release is Debian’s tag, not upstream.

[Justin Pasher]

Re: There's always something nowadays

Backported indeed.

https://security-tracker.debian.org/tracker/CVE-2018-1000007

[Anonymous Coward]

Any idea which RFC mandates that custom headers (which "Authorization" is not, anyway) must not or should not be resent when following redirects?

[charonn01]

In this context, "custom headers" refers to user-set headers (https://curl.haxx.se/libcurl/c/CURLOPT_HTTPHEADER.html) as opposed to headers set automatically by the library.

[Michael Wojcik]

None does, of course. The HTTP specifications (RFC 2616 for HTTP/1.1, etc) do not have any concept of "custom headers" in this sense. That is, they don't distinguish between headers the user agent adds by default, and ones it adds in response to some user action.

In fact RFC 2616 doesn't say much at all about the Location header (14.30). User agents aren't required to do anything with it.

I think this vulnerability is bogus, and the fix is wrong. If the user agent is sending sensitive information to the server (and that includes an Authorization header, Cookie header, etc), then it is affording the server some trust. If the server can send back a malicious Location header, that trust was an error on the part of the user agent or of the user. It doesn't matter whether the server is originally malicious, broken, compromised, impersonated, or possessed of Satan.

Any threat model where this vulnerability increases risk has to be hopelessly contrived.

I don't recognize the researcher (Craig de Stigter). The patch was made by Daniel Stenberg, who's a smart guy, but may have been too quick in evaluating the purported problem.

(A real fix would be to move to a user-authentication mechanism that can't easily be replayed and doesn't leak information to a malicious server or observer. ZKP-based techniques such as SRP have been around for decades, yet on the web we're still using a mix of awkward, unsafe approaches such as HTTP Basic Auth, plaintext credentials submitted through HTML forms, OAuth, symmetric X.509 authentication, and proprietary mechanisms.)