On Sun, Dec 01, 2019 at 02:37:14AM +0100, Florian Zumbiehl wrote: > 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". The vulnerability you describe in a browser is not that the credentials are used or that they are leaked somewhere – because they aren't, the intended receiver gets them – the problem is that with the state already present in the browser (which can be credentials, but also e.g. cookies) you can 'automate' things as if the user made that request intentionally – like deleting the account, authorizing a bank transfer or post some content. None of these things can happen with apt: It is accessing static data the user is allowed to receive by knowing the auth, there is no operation performed or content uploaded the user didn't intend to allow as there is nothing for them to allow. > > > 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 manpage says: | If no port is given the token matches for all ports Anyhow, you are either starting from the position of a HTTP source where you need to be an MITM to make use of this "vulnerability" to … well, do what you can already do because you are a MITM anyhow. That is the problem of a HTTP source, we can't fix that. Or it is a HTTPS source, but if you can attack those you again don't need this as you are again a MITM apparently with access to the private keys of the server which reduces the problem down to HTTP. So, yeah, if you are super specific in these stanzas you can prevent an attacker form slipping in by breaking & entering via an unsecured window, but that is not really improving anything as the attacker is already in via the open front door. > > > - 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?! You didn't explain well, so Julian misunderstood you. I think you where trying to say that http://foo.example.org is made to redirect to http://bar.example.org which would sent the auth for bar.example.org over the wire unencrypted (and so could be observed by a MITM) even if you usually access via https://bar.example.org (note the s). True, but that is why we allow you to set a port number! Note that you don't have this problem if you use client certificates which is the recommended way of auth in apt for https. Using sources.list to set the auth isn't issue free btw: To keep your password a secret from everyone with access to your machine, you need to keep your sources.list secret – but that causes many issues as a bunch of software wants access to the file for good (or not so good) reasons, which is solved by auth.conf at the expense of perhaps allowing slightly more mischief by a fullpowered MITM (honestly, I believe you are more likely to use software on your machine which can leak that data than encountering a powerful MITM which is interested in that data, but feel free pick your poison). > > > - 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? Welcome to the internet and "man in the middle" (MITM) attacks. You are a couple of years to late for that. See "https everywhere" efforts around the internet. Note though that whatever apt got still needs to pass verification, so whatever you got is still signed by a key you trust. apt has also a couple other checks in place which will likely trigger like metadata mismatches compared to previously acquired data. No idea though what you mean with "leaking content". The user is quite obviously allowed to see the content as they have the password for it, so nothing is leaked to the user and "used in a context it wasn't meant for" … if valid repository data isn't intended to be downloaded in this very context I don't know what is. So, please explain in detail what attacks you envision which aren't inherent in the used protocols (http) and targeting static content. It is also a good idea to first understand what apt actually does in an update command and the multitude of checks it deploys as many things are covered by these already which for other more generic internet clients remain a huge problem. So far I see only very generic guess and maybe-ifs which are not actionable and very much not a release critical bug – mostly because I don't see an actual bug be described so far… (also, it is a good idea /if/ you found a security problem to disclose it more responsibly to the security teams involved so they can coordinate fixes, patches and uploads. If you don't do that you are forcing the hand of the involved people, which tends to cause more aggressive and crisply responses as they are forced to deal with things NOW.) Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature