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 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
Reply to: