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) 945911@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
> 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.
(summary: Breaks redirects / too complex / not feasible to implement / non-standard)
Tying auth.conf entries to sources.list entries would break any form of
redirect, which is not how http (or the auth.conf format) is supposed to
work, hence it is a less agreeable solution.
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.
Notably, auth.conf entries do not necessarily match sources.list entries,
as they may only protect a part of the repository, and different parts might
even have different credentials. Tying that together does not seem feasible.
I'm confident that the proposed solution is the most effective one - it's feasible
to implement (and backport to stable releases, if there is agreement that this is
something to be fixed in stable releases).
It also matches what other software does, such as web browsers (I can redirect you
from my site to your site that needs auth just fine in a web browser, it won't say
"oh but you are not allowed to redirect", or strip away any basic auth or cookies).
And .. I wrote too much text and would have lost my attention span by now.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: