Hi, > > > 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.
1. Yes, the problem with CSRF is very much that credentials are used where they shouldn't be. For one, "credential" is not the name of a protocol field, it's a function of a piece of information. When a cookie authorizes you to perform an operation, then that cookie is a credential. And then, the fact that the credentials are sent to the intended receiver is just completely besides the point, because that is exactly the problem with confused deputy style vulnerabilities: The deputy uses privileges it has (such as credentials that allow it to perform a certain access) to perform an operation requested by a party that doesn't have those privileges and that shouldn't have those privileges. To maybe use a different example: Just because your company's access badge is intended to be presented to your company, does not mean that everything is fine when someone tricks you into presenting your badge in order to get them into the building. (And the solution to CSRF is to require another credential, AKA "CSRF token", when performing operations where the browser security model otherwise would allow confused deputy style attacks, and to keep that credential out of reach for other origins.) 1. Please note that I did not say APT had a CSRF vulnerability. I simply used a different confused deputy style vulnerability that you might be more familiar with to demonstrate a point. So, no, you probably can not get APT to authorize a bank transfer. But, again, the fact that the user is allowed to access the data is completely besides the point. The user is also allowed to look at their bank transactions in their online banking, but still, a browser's security model prevents any other random website from accessing them, because *the other website is not the user*. > > > > 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 And how does it follow that therefore you are vulnerable? > 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. I have no idea what you are talking about here!? In particular I don't understand where you got that MitM from ... none of the scenarios I described require a MitM!? I mean, yes, a MitM could potentially also exploit some of this, sure, but it's certainly not limited to MitM. > > > > - 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). That doesn't require MitM, but other than that, yes. > True, but that is why we allow you to set a port number! Note that you 1. So, how does setting a port number stop this attack? 2. Even if it did, the documentation doesn't explain this. > don't have this problem if you use client certificates which is the > recommended way of auth in apt for https. Which is relevant how? Is your point that if there is some safe scenario that an extra diligent user might find out how to set up, then there is no vulnerability, no matter how badly the software behaves in every other scenario? > 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). What is your point?! The safe way to configure server credentials causes other problems, therefore we shouldn't make the way that wouldn't cause those problems safe?! And also, other software has vulnerabilities, too, so why should we fix vulnerabilities in this one? I completely fail to understand what your argument is here if it's not those. Also, still, none of the example attack scenarios I gave require a MitM. > > > > - 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 Would you mind pointing to the MitM in that scenario? > 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 So, you have an additional confused deputy built into APT that gets just as confused as the first one ... and that is supposed to help how? > trust. apt has also a couple other checks in place which will likely > trigger like metadata mismatches compared to previously acquired data. Could you quantify that "likely"? As in, how likely precisely is that to prevent attacks? > 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 Yes, the user is, the other server is not ... > 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. Yes, bank transactions are also intended to be downloaded by the browser. That does not mean that they are intended to be accessed by other websites in that browser. > So, please explain in detail what attacks you envision which aren't > inherent in the used protocols (http) and targeting static content. I have, though it seems like I overestimated your understanding of IT security, so maybe my further explanations have helped with that? None of these issues is "inherent in HTTP", and also, *static* content does not imply *public* 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, does APT check that the files it downloaded could be known by the server named in the sources.list that the download attempt started at? (No, almost certainly not, because there is no binding between sources.list entries and signing keys--I am pretty sure my understanding of APT's security mechanisms is good enough to conclude that there is no reliable defense against this attack in any of the scenarios I described, let alone all of them.) > 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… Well, that is unfortunate!? > (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.) You are assuming that people who would exploit this sort of vulnerability don't know about it, which seems very unlikely given how blatantly obvious it is to anyone with such a background. Regards, Florian
