> > The credentials to transmit for a request are selected not based on the > > host name specified in the sources.list, but rather based on the URI that > > is being requested. Thus, any repository server that APT ever makes an > > HTTP(S) request to can issue an HTTP redirect to any URI that points to any > > of the (other) servers for which credentials are stored in the auth.conf > > file, and APT will then send those credentials to whatever endpoint that is > > specified as the redirection target URI. > > Yes, and why please tell, should that be a problem? That's how stuff
Because it might allow operations to happen that the user did not intend to allow. > works. If I requests https://a/b/c and it redirects me to https://x/y/z, > I need login details for x/y/z to login. It may well be that you _need_ them. But that doesn't say anything about whether you should _get_ them. When a web server instructs a browser to submit some request to a different origin, that request may also _need_ credentials for that other origin to perform some operation. But just allowing any web server to submit requests to any other origin with all credentials the browser knows about still is considered a vulnerability, known as "cross site request forgery". Just because https://x/y/z needs credentials to be accessed, does not mean that https://a/b/c should be allowed to cause such an access. > Saying we should send the credentials for a/b/c to x/y/z does not make > a whole lot of sense. Indeed, it doesn't, and maybe I was not entirely clear on this, but I certainly didn't intend to suggest anything like that. > This also assumes that you have access to the a/b/c server _and_ the > x/y/z server. Yes ... so?! > > Examples for how this could be exploited are: > > > > - The redirect could point to a different port on the server than where the > > repository is hosted, possibly an unprivileged port where an attacker on > > that server could be listening to receive the credentials. > > I don't understand. FWIW; credentials can be limited by port, and path. Yes, they can. But it is absolutely not clear from the documentation that you are vulnerable to this type of attack if you don't do that. And even if this were stated clearly in the documentation, it would still be bad default behaviour. > > - The redirect could point to an HTTP URI to expose the credentials as > > plain text on the wire, even where the sources.list entries for the > > respective server point only to HTTPS URIs to protect from eavesdroppers. > > HTTPS->HTTP redirects are not allowed. Well, that's good, I suppose? But it's also irrelevant for this attack scenario?! > > - The redirect could point to an existing resource in the repository the > > credentials are actually meant for in order to make APT download that > > resource and then use it in a context it wasn't meant for, thus > > potentially leaking contents of the password-protected repository. > > I don't understand. You specify in the sources.list: | deb http://public.mirror.example/debian buster main In auth.conf: | machine internal.server.example | login top | password secret Now, when you request some package list or something from public.mirror.example, public.mirror.example could redirect you to http://internal.server.example/whatever/file, and APT would then treat that file as if it were the packages list that is found on public.mirror.example - I suppose? I haven't tried to build a PoC for this, so no clue how exactly you would exploit this particular scenario.
