Bug#945911: APT leaks repository credentials
Hi, > > Except ... this scenario was not about having access to a > > password-protected server, but about eavesdropping on the route to it?! > > "Eavesdropping on the route to it" is a MitM attack, precisely the (2) listed > above, because um, duh, the route to it is in the middle. You were the one No, eavesdropping, as per the established terminology in IT security, means the power to listen in on communication, while MitM means the power to also modify it. The latter is not necessary for this attack scenario, therefore, no MitM is required. > > Which would be a problem on a trusted network how? To take the maybe most > > extreme scenario: How is it a security problem to use plain text HTTP > > credentials on localhost? > > On a trusted network, the attack implies that the attacker has taken over > _both_ > a public mirror _and_ gained access to the internal repository hosting machine > on your trusted network. I think you have a bigger problem here? For one, it does not imply that the attacker has taken over a public mirror, they could simply be a legitimate operator/admin of a public mirror. As I understand it, the security model of APT is to distrust mirror operators, thus, attack vectors usable by mirror operators would have to be considered vulnerabilities?! But also, why would "gain[ing] access to the interal repository hosting machine" be a (bigger) problem?! I mean, for one, it is perfectly sensible to have users on a system that are not supposed to have root access to the machine, or access to all the software repositories that it has access to, even if those happen to be hosted on that same machine. But also, even if an outside attacker has managed to gain unauthorized access to an unprivileged user account: Why would that be a reason to say that it's pointless to prevent escalation of privileges after that point? And how does that fit with the idea of running daemons as unprivileged users to limit the damage a compromise can do? Really, what all of this boils down to is this: Why do you think that user privileges on Unix machines have no relevance, and access as one user on a machine should be expected to imply access beyond that user's account (and therefore, escalation of privileges within the system is somehow not a vulnerability)? Or am I misinterpreting your position there? > Also, is the > network still a trusted one when you have an attacker taking over one of its > machines? Having unprivileged access to a machine that is connected to a trusted network does not imply compromise of that trusted network in any way, even if the access is unauthorized: As long as the kernel and root account are not compromised, there is still no way for the attacker to either listen in on traffic on the network, nor to gain a MitM position on connections on that network, nor to impersonate the machine they are on via privileged ports. The only power with regards to that network would be to make connections from or listen on unprivileged ports on that hosts't address(es)--which could be a problem if other components assume that that can not happen, but is not relevant to the discussion at hand, as the premise was that the HTTP server requires HTTP authentication, which can not be compromised this way. > > Also, I would think that install is the thing that in and of itself is not > > vulnerable to this at all, because the contents of the package file are > > cryptographically bound to the package lists, so at worst an attacking > > server could redirect you to a file that APT will just reject anyway, which > > is no increased privilege over just sending you a random wrong file in the > > first place, which a server could always do anyway? > > There is no difference between install and anything else. > > I'm not sure you understand how a Debian repository works. Let me explain: > > It's roughly a merkle tree, with the root signed by gpg. Hence, everything is > (possibly transitively) signed. [...] Yes, that's how I understood it to work. But "signed" is not equivalent to "secure". "Signed" only means "was not modified vs. the state seen by the signer". So, assuming the signer is trusted, the question then is: What are the semantics of the state that the signer saw (and signed)? That is: What statement did the signer certify when they made that signature? In the case of the root signature on APT repositories, that statement is, roughly: "The packages and their meta data that can be downloaded by following the references in this document were placed into this repository based on the rules that govern this repository." The one crucial thing that the signature does not certify is: "The contents of this document are what you intended to download with the URI you specified in your sources.list." And that is the difference between update and install: All install packages are cryptographically bound to the package lists and stuff up to
Bug#945911: APT leaks repository credentials
On Tue, Dec 03, 2019 at 04:58:57AM +0100, Florian Zumbiehl wrote: > Hi, > > > > > > > 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. > > > > > > > > 1) Yes, they do require MitM > > > > > > No, they don't. > > > > > > >(1) MITM on the DNS to hihack requests to bar to your own server > > > > > > Nothing of the sort. > > > > > > >(2) MITM on the Network routing to directly read requests > > > > > > 1. Reading requests does not require MitM. > > > > > > 2. Nothing of that sort either. > > > > OK, it does not _require_ MitM. It's just substantially more realistic. > > > > (details:) > > It's highly unlikely that you'll gain control to both a public mirror > > as root / www-data user) _and_ a password-protected one (as any user), hence > > that did not even cross my mind. The MitM attack scenario is substantially > > more realistic, and would have been an easier introduction :) > > Except ... this scenario was not about having access to a > password-protected server, but about eavesdropping on the route to it?! "Eavesdropping on the route to it" is a MitM attack, precisely the (2) listed above, because um, duh, the route to it is in the middle. You were the one saying that the attack does not require a MitM, so I managed to came up with the one scenario that does not. > > > However, it certainly would not fix the third scenario, and it would also > > > not fix the first scenario in the case where people do explicitly > > > configure > > > credentials for HTTP, such as for internal servers that are accessed > > > through a trusted network where eavesdropping is not a concern. > > > > (summary: the other scenarios are not relevant) > > > > The first scenario was for a different port. The port can already be > > hardcoded, we could default to port 443 for https, rather than any port. > > How is it relevant that a user who happens to be aware that APT is > vulnerable, even though even the documentation doesn't say so, can manage > to (partially) work around that vulnerability? Does that make the average > user any more secure? > > Defaulting to restricting the port would obviously stop more potential > attacks, as well as just accidental leaks due to the potentially somewhat > surprising (albeit documented) current behaviour, so I'd think it's > probably a good idea. But it's not a complete solution to this > vulnerability either. I don't think the behavior is surprising at all, it's totally what you would expect to happen in a download client with an authentication database. > > Now, if you use credentials on an http repository, you are lost anyway, > > a request with the credentials in plain text will be made whether or not > > Which would be a problem on a trusted network how? To take the maybe most > extreme scenario: How is it a security problem to use plain text HTTP > credentials on localhost? On a trusted network, the attack implies that the attacker has taken over _both_ a public mirror _and_ gained access to the internal repository hosting machine on your trusted network. I think you have a bigger problem here? Also, is the network still a trusted one when you have an attacker taking over one of its machines? > Also, I would think that install is the thing that in and of itself is not > vulnerable to this at all, because the contents of the package file are > cryptographically bound to the package lists, so at worst an attacking > server could redirect you to a file that APT will just reject anyway, which > is no increased privilege over just sending you a random wrong file in the > first place, which a server could always do anyway? There is no difference between install and anything else. I'm not sure you understand how a Debian repository works. Let me explain: It's roughly a merkle tree, with the root signed by gpg. Hence, everything is (possibly transitively) signed. We know the size and hash of every file we are downloading, except for the root file(s). But we do have upper limits set for them, and will not download files bigger than those. And then the signature is verified, and we find the other files we are interested in, and download them (and if the response has the wrong size, or the wrong hash, we fail with an error). > > Redirects are already fairly complex, and adding policies on which server > > is allowed to redirect to which server is not going to make anyone happy. > > I don't see any need to restrict which server is allowed to redirect to > which server!? What you need is a way to restrict which server is allowed >
Bug#945911: APT leaks repository credentials
Hi, > > > > > 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. > > > > > > 1) Yes, they do require MitM > > > > No, they don't. > > > > >(1) MITM on the DNS to hihack requests to bar to your own server > > > > Nothing of the sort. > > > > >(2) MITM on the Network routing to directly read requests > > > > 1. Reading requests does not require MitM. > > > > 2. Nothing of that sort either. > > OK, it does not _require_ MitM. It's just substantially more realistic. > > (details:) > It's highly unlikely that you'll gain control to both a public mirror > as root / www-data user) _and_ a password-protected one (as any user), hence > that did not even cross my mind. The MitM attack scenario is substantially > more realistic, and would have been an easier introduction :) Except ... this scenario was not about having access to a password-protected server, but about eavesdropping on the route to it?! And in any case, I'd be interested to know how you quantify those probabilities. > > I really don't see how I could have been any more focused than that. > > I don't know, give some urls and a succinct relevant example: > > "Given two repos http://public.mirror.example/ and > https://internal.repo.example/: > > Make http://public.mirror.example/ redirect to > http://internal.repo.example:443/, > and apt is sending auth.conf credentials meant for the encrypted repo in > plain text. > " > > It makes you see immediately that something is wrong vs a wall of prose text > that you have to parse and make sense of - which I hilariously failed at, but > then it was 11pm on a Saturday night. Well, maybe, but then, that is arguably the exact opposite of being more focused, in that it shows a more or less random example of a possible attack, rather than pointing out the underlying cause. > > However, it certainly would not fix the third scenario, and it would also > > not fix the first scenario in the case where people do explicitly configure > > credentials for HTTP, such as for internal servers that are accessed > > through a trusted network where eavesdropping is not a concern. > > (summary: the other scenarios are not relevant) > > The first scenario was for a different port. The port can already be > hardcoded, we could default to port 443 for https, rather than any port. How is it relevant that a user who happens to be aware that APT is vulnerable, even though even the documentation doesn't say so, can manage to (partially) work around that vulnerability? Does that make the average user any more secure? Defaulting to restricting the port would obviously stop more potential attacks, as well as just accidental leaks due to the potentially somewhat surprising (albeit documented) current behaviour, so I'd think it's probably a good idea. But it's not a complete solution to this vulnerability either. > It's also fairly irrelevant, as you still need access to the certificate > and for all intents and purposes, if you have the certificate you are > proofing that we are talking to the correct server. Well, APT does support plain text HTTP with credentials ... so plain text HTTP with credentials should be implemented securely in APT, shouldn't it? > Now, if you use credentials on an http repository, you are lost anyway, > a request with the credentials in plain text will be made whether or not Which would be a problem on a trusted network how? To take the maybe most extreme scenario: How is it a security problem to use plain text HTTP credentials on localhost? > the redirect exists (and woohoo, that happens in the background automatically, > at a completely random time). Does it? How do you know? > Having a redirect increases your chances ever so slightly, because you can use > a redirect for install, rather than the attack only working for update, but > that > is a relatively minor concern. Erm ... having the redirect is what enables an otherwise impossible attack!? Also, I would think that install is the thing that in and of itself is not vulnerable to this at all, because the contents of the package file are cryptographically bound to the package lists, so at worst an attacking server could redirect you to a file that APT will just reject anyway, which is no increased privilege over just sending you a random wrong file in the first place, which a server could always do anyway? > > Ultimately, to solve a confused deputy problem, you have to allow the user > > to specify who is allowed to use a given set of credentials, which in this > > case in particular means which server is allowed
Bug#945911: APT leaks repository credentials
On Mon, Dec 02, 2019 at 03:36:20AM +0100, Florian Zumbiehl wrote: > > > > > > > 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. > > > > 1) Yes, they do require MitM > > No, they don't. > > >(1) MITM on the DNS to hihack requests to bar to your own server > > Nothing of the sort. > > >(2) MITM on the Network routing to directly read requests > > 1. Reading requests does not require MitM. > > 2. Nothing of that sort either. OK, it does not _require_ MitM. It's just substantially more realistic. (details:) It's highly unlikely that you'll gain control to both a public mirror as root / www-data user) _and_ a password-protected one (as any user), hence that did not even cross my mind. The MitM attack scenario is substantially more realistic, and would have been an easier introduction :) > That is the core problem, and redirects are the mechanism that enables > this, because redirects are how an attacking server (or potentially a MitM, > of course) can instruct APT to issue an HTTP request to a URI of its > choosing, using credentials that are not meant to be used by that server, > thus acting as a confused deputy. > > I really don't see how I could have been any more focused than that. I don't know, give some urls and a succinct relevant example: "Given two repos http://public.mirror.example/ and https://internal.repo.example/: Make http://public.mirror.example/ redirect to http://internal.repo.example:443/, and apt is sending auth.conf credentials meant for the encrypted repo in plain text. " It makes you see immediately that something is wrong vs a wall of prose text that you have to parse and make sense of - which I hilariously failed at, but then it was 11pm on a Saturday night. > The following you sent to (me and) 945...@bugs.debian.orgg, which I suppose > was a typo, so I am quoting it here: eek, typos are evil. should not type emails at night. > > > On Sun, Dec 01, 2019 at 09:35:46PM +0100, Julian Andres Klode wrote: > > [...] > > > 1) Yes, they do require MitM > > > > > >(1) MITM on the DNS to hihack requests to bar to your own server > > >(2) MITM on the Network routing to directly read requests > > > > > > 2) In practice, credentials are combined with HTTPS. We do not allow > > >HTTP to HTTPS redirects, hence you need to actually have certificates > > >for _both_ foo and bar. > > > > I'm sorry, this was of course wrong, e.g. if you use http:/deb.debian.org/ > > and https://internal.example/, the former can send to APT > > > > Location: http://internal.example/ (possibly with a :443 port) > > > > and apt would happily send the credentials in plain text. Fixing apt to > > send credentials only over https unless configured otherwise (per auth.conf > > entry) would fix it :-) > > That would be the second example scenario that I listed in my original bug > report, yes, and defaulting to sending credentials over HTTPS only would > indeed fix that scenario. > > However, it certainly would not fix the third scenario, and it would also > not fix the first scenario in the case where people do explicitly configure > credentials for HTTP, such as for internal servers that are accessed > through a trusted network where eavesdropping is not a concern. (summary: the other scenarios are not relevant) The first scenario was for a different port. The port can already be hardcoded, we could default to port 443 for https, rather than any port. It's also fairly irrelevant, as you still need access to the certificate and for all intents and purposes, if you have the certificate you are proofing that we are talking to the correct server. Now, if you use credentials on an http repository, you are lost anyway, a request with the credentials in plain text will be made whether or not the redirect exists (and woohoo, that happens in the background automatically, at a completely random time). Having a redirect increases your chances ever so slightly, because you can use a redirect for install, rather than the attack only working for update, but that is a relatively minor concern. > Ultimately, to solve a confused deputy problem, you have to allow the user > to specify who is allowed to use a given set of credentials, which in this > case in particular means which server is allowed to "use" a given set of >
Bug#945911: APT leaks repository credentials
Hi, > [ lots of blah blah ] .o() > > > > > > - 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. > > 1) Yes, they do require MitM No, they don't. >(1) MITM on the DNS to hihack requests to bar to your own server Nothing of the sort. >(2) MITM on the Network routing to directly read requests 1. Reading requests does not require MitM. 2. Nothing of that sort either. > On further thought, I'd like to add a "proto" field to auth.conf, > defaulting to https, tor+https, so we can look at that, and only > send credentials over encrypted connections. Or should we parse the > protocol out of the machine field? idk. (specifying port 443 would > not help as much, as you could do http over 443). Well, that's certainly not a bad idea, and would even stop many of the possible attacks, but it's not a full solution to the problem. > This prevents us from sending credentials to men in the middle, > and should hence address all of your concerns. No, it wouldn't, plus still no MitM. > The security implications of this are minimal, and the change is > not suitable for backporting to older releases. Well, I obviously disagree, at least on the former. > I just have to say it was hard to figure out what the problem is, > with your sidelines to redirects, and your saying there is no mitm > involved, when the bug report basically comes down to "people can > mitm http connections, and you'd send credentials over them". A more > focused and thought out bug report would have been useful. Erm, wut? You simply invent that it's a MitM problem, when it's not, that it's not about redirects, when it is, and then complain that I am not explaining clearly that it is about MitM and not about redirects!? The second sentence of my original bug report was: | Unfortunately, the way these credentials are handled causes a confused | deputy style problem: That is the core problem, and redirects are the mechanism that enables this, because redirects are how an attacking server (or potentially a MitM, of course) can instruct APT to issue an HTTP request to a URI of its choosing, using credentials that are not meant to be used by that server, thus acting as a confused deputy. I really don't see how I could have been any more focused than that. The following you sent to (me and) 945...@bugs.debian.orgg, which I suppose was a typo, so I am quoting it here: > On Sun, Dec 01, 2019 at 09:35:46PM +0100, Julian Andres Klode wrote: > [...] > > 1) Yes, they do require MitM > > > >(1) MITM on the DNS to hihack requests to bar to your own server > >(2) MITM on the Network routing to directly read requests > > > > 2) In practice, credentials are combined with HTTPS. We do not allow > >HTTP to HTTPS redirects, hence you need to actually have certificates > >for _both_ foo and bar. > > I'm sorry, this was of course wrong, e.g. if you use http:/deb.debian.org/ > and https://internal.example/, the former can send to APT > > Location: http://internal.example/ (possibly with a :443 port) > > and apt would happily send the credentials in plain text. Fixing apt to > send credentials only over https unless configured otherwise (per auth.conf > entry) would fix it :-) That would be the second example scenario that I listed in my original bug report, yes, and defaulting to sending credentials over HTTPS only would indeed fix that scenario. However, it certainly would not fix the third scenario, and it would also not fix the first scenario in the case where people do explicitly configure credentials for HTTP, such as for internal servers that are accessed through a trusted network where eavesdropping is not a concern. Ultimately, to solve a confused deputy problem, you have to allow the user to specify who is allowed to use a given set of credentials, which in this case in particular means which server is allowed to "use" a given set of credentials (by issuing a redirect), and the default policy should allow only credentials to be used that match the entry in the sources.list that is being processed. Regards, Florian
Bug#945911: APT leaks repository credentials
Control: reopen -1 Control: retitle -1 only send credentials over https by default Control: severity -1 normal On Sun, Dec 01, 2019 at 09:35:46PM +0100, Julian Andres Klode wrote: > On Sun, Dec 01, 2019 at 08:36:05PM +0100, Florian Zumbiehl wrote: > > Hi, > > > [ lots of blah blah ] > > > > > > > > - 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. > > 1) Yes, they do require MitM > >(1) MITM on the DNS to hihack requests to bar to your own server >(2) MITM on the Network routing to directly read requests > > 2) In practice, credentials are combined with HTTPS. We do not allow >HTTP to HTTPS redirects, hence you need to actually have certificates >for _both_ foo and bar. > > 3) If we have credentials for bar configured, we'll also usually have bar >in sources.list, hence we will make equests to bar in any case, whether >or not foo redirects to it. > >Apart from some imaginable exceptions where people configure a central >load balancer that sends redirects to internal repos and configure >passwords for those end points; in which case, you know, the behavior >is precisely what they want. > > Since the rest of your email is basically the same message, I'll not > quote it and repeat myself. > On further thought, I'd like to add a "proto" field to auth.conf, defaulting to https, tor+https, so we can look at that, and only send credentials over encrypted connections. Or should we parse the protocol out of the machine field? idk. (specifying port 443 would not help as much, as you could do http over 443). This prevents us from sending credentials to men in the middle, and should hence address all of your concerns. The security implications of this are minimal, and the change is not suitable for backporting to older releases. I just have to say it was hard to figure out what the problem is, with your sidelines to redirects, and your saying there is no mitm involved, when the bug report basically comes down to "people can mitm http connections, and you'd send credentials over them". A more focused and thought out bug report would have been useful. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#945911: APT leaks repository credentials
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 > > > >
Bug#945911: APT leaks repository credentials
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
Bug#945911: APT leaks repository credentials
> > 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.
Bug#945911: APT leaks repository credentials
Control: tag -1 moreinfo On Sat, Nov 30, 2019 at 10:36:29PM +0100, Florian Zumbiehl wrote: > Package: apt > Version: 1.8.2 > Severity: critical > > APT now promotes using auth.conf to store repository credentials. > Unfortunately, the way these credentials are handled causes a confused > deputy style problem: > > 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 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. Saying we should send the credentials for a/b/c to x/y/z does not make a whole lot of sense. This also assumes that you have access to the a/b/c server _and_ the x/y/z server. > > 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. > > - 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. > > - 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. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#945911: APT leaks repository credentials
Package: apt Version: 1.8.2 Severity: critical APT now promotes using auth.conf to store repository credentials. Unfortunately, the way these credentials are handled causes a confused deputy style problem: 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. 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. - 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. - 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. IMO, credential use should be limited based on the the URI that was derived from the sources.list to prevent such exploits: The user should be able to trust that when they specify credentials for a specific server, say, then only sources.list entries that name that server get to use those credentials. Note: I did not investigate the source on this, I just tested this manually with socat, redirecting from one hostname to a different hostname on a random port, and in that scenario I got the credentials for the redirection target. So, it is possible that some of the scenarios above actually don't work for some reason, though it seems unlikely.
