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