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.
