Re: git clone with basic auth in url directly returns authentication failure after 401 received under some git versions

From: Daniel Stenberg <daniel@haxx.se>
Date: Aug 20, 2022, 22:32 UTC
Message-ID: <o4sp3o6-75sp-o12o-2p29-r94s2s769r47@unkk.fr>
In-Reply-To: <YwCe6ONEaeIj4SO/@coredump.intra.peff.net>

On Sat, 20 Aug 2022, Jeff King wrote:

Show 6 quoted lines

> The curl change seems to be from 620ea2141 (transfer: redirects to other
> protocols or ports clear auth, 2022-04-25). The goal is to avoid leaking
> credentials between ports: https://curl.se/docs/CVE-2022-27774.html
>
> So that makes sense, though I wonder if curl ought to make an exception
> for moving from 80 to 443 and http to https?

Nice research there Jeff, and yes this seems entirely correct.

We stopped curl from following such redirects because of the reasons stated in the security advisory for that CVE. We quite simply realized that when curl previously did that, it was actually doing more than what was documented and what can be considered reasonably safe.

Following a redirect to another protocol and another port, even if it is still on the same host name, might very well connect and use another server run by someone else than the one reached first. We therefore now consider that second host+port+protocol combo a different host.

Setting CURLOPT_UNRESTRICTED_AUTH is then the only way to make libcurl send the credentials again after such a redirect.

I would not mind having a discussion in the curl project to see if we should possibly consider adding a middle-ground where we allow sending credentials to another port for the same host name, but I am personally NOT sold on the idea. I think such redirects should rather be fixed and avoided - since I believe users will not understand the security implications of doing them.

-- 
  / daniel.haxx.se