I have not seen any discussion of what appears to be a very serious problem in Apt's security architecture.
According to the information here https://wiki.debian.org/SecureApt this attack should not work at all. Apt downloads the Release.gpg and Release files then verifies a valid signature using the built in debian keyring. Packages that are downloaded are hashed and hash compared to hash listed in the signed Release file. If an attacker intercepts the connection and inserts malware with a new hash it will not match the hash in the Release file. If the attacker provides a new Release file the signature would not match the key in the debian keyring. So how is this attack possible? Is apt simply accepting a hash provided from http fetcher process is valid? In this description of the attack https://justi.cz/security/2019/01/22/apt-rce.html it sounds like this is the sequence of events. 1. user requests update for package cowsay 2. deb.debian.org sends a redirect to mirror.somesite.org 3. attacker intercepts http redirect and appends a newline for http splitting attack followed by a forged 201 URI Done message with valid hashes as listed in the Release file 4. apt fails to verify file hashes and accepts attacker provided hashes 5. apt parses the attacker provided /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_Release.gpg file 6. apt manages to somehow unpack oops.deb file prepended to a detached gpg signature file despite that there is extraneous data and the file does not even end in .deb 7. apt installs attacker provided oops.deb file Is this right? If so, there seems to be more than one security problem here. 1. http fetcher blindly accepts potentially malicious input from the internet, but also 2. that apt accepts hashes from http fetcher without validation and 3. this is the only security check prior to installation. What has been done to fix this?