APT vulnerability [DSA 4371-1] discussion
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?
Reply to: