Bug#945911: APT leaks repository credentials

[Florian Zumbiehl <florz@florz.de>]

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.