Bug#945911: APT leaks repository credentials
Hi,
> [ lots of blah blah ]
.o()
> > > > > > - 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
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.
> 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).
Well, that's certainly not a bad idea, and would even stop many of the
possible attacks, but it's not a full solution to the problem.
> This prevents us from sending credentials to men in the middle,
> and should hence address all of your concerns.
No, it wouldn't, plus still no MitM.
> The security implications of this are minimal, and the change is
> not suitable for backporting to older releases.
Well, I obviously disagree, at least on the former.
> 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.
Erm, wut? You simply invent that it's a MitM problem, when it's not, that
it's not about redirects, when it is, and then complain that I am not
explaining clearly that it is about MitM and not about redirects!?
The second sentence of my original bug report was:
| Unfortunately, the way these credentials are handled causes a confused
| deputy style problem:
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.
The following you sent to (me and) 945911@bugs.debian.orgg, which I suppose
was a typo, so I am quoting it here:
> 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.
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.
Regards, Florian
Reply to: