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 the "root signature", so, if the update was not compromised, a redirect can not compromise the install either (apart from leaking credentials to third parties, of course), because only one completely predetermined file content will be accepted by APT. But that does not apply for the update, as the update is only constrained by the configured trusted keys, but any package lists that are signed by any of the trusted keys will be accepted from any repository server (I think?). > > > 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 > > to use which credentials. When a.example redirects to b.example, there is > > no problem with following that redirect, the problem is if you then also > > send the credentials for b.example in that redirected request, unless that > > was explicitly allowed by the user. > > This is precisely what I was talking about. Should I have added "redirect with > credentials"? Well, I would guess that the limiting of credentials should be quite a bit easier to implement in a way that should cover all practically relevant cases: Instead of actually specifying which *server* is allowed to use a set of credentials, you could specify which *sources.list entry* is allowed to use them, though possibly by selecting them based on server names/protocols/ports specified in sources.list, which would mean that you probably could simply filter which credentials you provide to the HTTP client before even starting the request processing? Making some assumptions about how APT handles HTTP requests, obviously ... I would guess that the scenario "A is allowed to redirect to B with credentials, B is allowed to redirect to C with credentials, but A should not be allowed to redirect to C with credentials" is sufficiently esoteric that noone really needs that. > > Well, I sure would think that leaking repository credentials is a > > vulnerability that should be fixed in stable releases?! And especially so > > in stable releases that promote using the vulnerable mechanism over the > > (presumably) safe setup of putting the credentials in the sources.list. > > Heh, you probably also think we should have disabled MD5 as a hash for gpg > signatures in stable releases. Or SHA1 in releases that still support it. You mean for repositories? Or for GPG in general? > Cross-origin request protection in web browsers pertains to preventing > JavaScript accesses to code operating in the foo domain to be able to > make requests in the bar domain. > > We don't have such problems. All we can do is fixed GET requests to > download signed data which we then verify before using it. Well, see above, the data is signed, but it does not say anything that could prevent "crossing origin boundaries", so verifying that signature does nothing to prevent this attack. It's a bit like if browsers checked same origin policy against the URI host name, but failed to check the URI host name against the certificate subject name, and only checked that the certificate is signed by some trusted root CA. > Yes, we're vulnerable to getting redirected to some control > interface that performs a side-effect on GET that happens to > have the same credentials as the stuff we want to access on > that machine. I would not consider that a vulnerability in APT: As per the HTTP spec, a client sending a request with a "safe method" does explicitly not request any side effects and is not responsible for them, so it is perfectly fine for APT to rely on that, and exclusively that control interface's fault if it does perform some problematic side effect anyway. Regards, Florian
