[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#945911: marked as done (APT leaks repository credentials)

Your message dated Sun, 1 Dec 2019 21:35:46 +0100
with message-id <20191201211940.GA3967421@debian.org>
and subject line Re: Bug#945911: APT leaks repository credentials
has caused the Debian Bug report #945911,
regarding APT leaks repository credentials
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
945911: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945911
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apt
Version: 1.8.2
Severity: critical

APT now promotes using auth.conf to store repository credentials.
Unfortunately, the way these credentials are handled causes a confused
deputy style problem:

The credentials to transmit for a request are selected not based on the
host name specified in the sources.list, but rather based on the URI that
is being requested. Thus, any repository server that APT ever makes an
HTTP(S) request to can issue an HTTP redirect to any URI that points to any
of the (other) servers for which credentials are stored in the auth.conf
file, and APT will then send those credentials to whatever endpoint that is
specified as the redirection target URI.

Examples for how this could be exploited are:

- The redirect could point to a different port on the server than where the
  repository is hosted, possibly an unprivileged port where an attacker on
  that server could be listening to receive the credentials.

- 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.

- The redirect could point to an existing resource in the repository the
  credentials are actually meant for in order to make APT download that
  resource and then use it in a context it wasn't meant for, thus
  potentially leaking contents of the password-protected repository.

IMO, credential use should be limited based on the the URI that was derived
from the sources.list to prevent such exploits: The user should be able to
trust that when they specify credentials for a specific server, say, then
only sources.list entries that name that server get to use those
credentials.

Note: I did not investigate the source on this, I just tested this manually
with socat, redirecting from one hostname to a different hostname on a
random port, and in that scenario I got the credentials for the redirection
target. So, it is possible that some of the scenarios above actually don't
work for some reason, though it seems unlikely.

--- End Message ---
--- Begin Message --- 
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.

I'm hereby closing this report.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

--- End Message ---
Reply to: