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
> 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"?
>
> > (and backport to stable releases, if there is agreement that this is
> > something to be fixed in stable releases).
>
> 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.
> But also, does this actually match what browsers do?
>
> Can you use a redirect in order to access data from a different origin? No,
> you can't, because the same origin policy prevents that access. While it is
> true that a web server can instruct a browser to request a different URI,
> and that request will contain any HTTP authentication credentials or
> cookies the browser knows about for that URI's origin, the browser will
> process the result of that request within the constraints of that URI's
> origin, and the redirecting server has no way to access it. Or rather, the
> only way to gain access to that data is if the target origin of that
> redirect cooperates via mechanisms like CORS to explicitly authorize that
> access. For side effect free requests, the same origin policy prevents
> confused deputy attacks--and I don't think there is any comparable
> mechanism in APT?
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.
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.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: