Bug#945911: APT leaks repository credentials
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?!
And in any case, I'd be interested to know how you quantify those
probabilities.
> > 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.
Well, maybe, but then, that is arguably the exact opposite of being more
focused, in that it shows a more or less random example of a possible
attack, rather than pointing out the underlying cause.
> > 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.
> 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.
Well, APT does support plain text HTTP with credentials ... so plain text
HTTP with credentials should be implemented securely in APT, shouldn't it?
> 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?
> the redirect exists (and woohoo, that happens in the background automatically,
> at a completely random time).
Does it? How do you know?
> 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.
Erm ... having the redirect is what enables an otherwise impossible
attack!?
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?
> > 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,
Hu? Why?
> which is not how http (or the auth.conf format) is supposed to
> work, hence it is a less agreeable solution.
Not sure what your point is here? HTTP and the auth.conf format are
supposed to be vulnerable?!
> 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.
> 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.
Well, is the primary goal to have secure software or to have "feasible"
software? And if it's the latter, then you maybe at least should advertise
that so users know that they should expect known unfixed vulnerabilities?!
As for auth.conf entries not necessarily matching sources.list entries:
Well, then those might just require explicit configuration by the user to
tie them together?
> I'm confident that the proposed solution is the most effective one - it's feasible
> to implement
... but vulnerable and thus not a solution!?
> (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.
> 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).
I am not really sure what your point is here?!
I mean, let's assume that this matches what other software does. Does the
fact that other software also does something make whatever that other
software is doing not a vulnerability? Like, if other software has a buffer
overflow that allows for root access to a machine, does that mean that your
buffer overflow that allows for root access to a machine is not a
vulnerability?
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?
Also, one reason why I said above that the default handling of port
restrictions for credentials is surprising is because it is very different
from what the standard on the web is, i.e., from what browsers do: Any HTTP
auth credentials you provide to a browser are scoped by origin, and the
origin is defined by protocol, host, and port.
Now, it is true that you can also get browsers to submit requests with HTTP
methods that are not guaranteed to be side effect free to foreign origins,
with credentials for those origins. But that is very much considered a
vulnerability!
Unfortunately is just so happens that this vulnerability is in an
interoperable system with thousands of implementations and billions of
deployed instances, so there is no way to just fix it in the spec without
major backwards compatibility headaches--which is why instead every web
application developer has to protect against this vulnerability in their
application code to make sure this vulnerability in the underlying protocol
does not translate into a vulnerability in their application.
Namely: Every web application developer needs to make sure that requests
that cause side effects and that require authentication do not ever rely
solely on HTTP auth and/or cookies for that purpose. If your web
application performs operations with side effects based on authentication
using only HTTP auth and/or cookies, then *your web application is
universally considered vulnerable*, and not only is it considered
vulnerable, there is even a name for that vulnerability: CSRF. Plus,
browsers do provide mechanisms that are not vulnerable that allow you to
solve that problem, and browser vendors most definitely do not encourage
you to use (exclusively) the vulnerable mechanisms that they implement for
backwards compatibility reasons, very much the opposite.
And yes, among those mechanisms provided by browsers for cross-origin
requests in the context of CORS is the option for the web site/application
to specify that a certain request to a foreign origin should be executed
without credentials (which is kindof backwards, of course, but that's just
a side effect of the backwards compatibility to vulnerable historical
practices) as a way to signal to the server "I only want public responses
that are allowed to be exposed to untrusted origins".
I very much doubt that APT has any mechanisms that even remotely come close
to the efforts of browser vendors to compensate for the vulnerabilities in
the HTTP auth and cookie mechanisms?!
Regards, Florian
Reply to: