No word as of yet if Ubuntu's apt is also impacted.
Sounds like the vulnerability is in the HTTP handling code, and because apt downloads packages over plain HTTP a man-in-the-middle position would be enough to exploit it.
It almost seems like a repeat of two previous apt vulnerabilities:
Despite with the 'no need for TLS, apt packages are signed' clowns would have you believe, you can usually point to a package mirror with https. This has the added advantage of preventing a mitm from knowing what packages you install or blocking selected packages.
Of course not, Debian is one of the most robust pieces of software around. They wouldn't do something idiotic like relying on the hash being sent with the payload through the same channel.
I think the idea is that debian distributes the hash themselves through their domain, and mirrors offer the downloads either through http or https. So that you don't need to trust the mirror, you just verify the debian given hash. Only weakness would be a hash collision or a cve like this.
Well, of course there is "Selbstreparaturparadoxon", but nobody uses that. This is more like a Münchhausen-Problem, where Baron Münchhausen pulls himself out of the swamp by his own hair.
There have already been quite a few vulnerabilities in the implementation that would have been avoided if the transport itself was simply protected in line with the industry standard practice of using TLS by default.
Yikes, that vuln in apt is pretty bad! I think a lot of the newer wave of vulnerabilities being found generally seem to have a low likelihood of being reached, but this seems somewhat plausible? I'm assuming this would be done by compromising a mirror, in order to do the redirect?
More likely just a man in the middle attack. Apt typically uses HTTP (no TLS) as the signatures give the security. But in this case it sounds like the vulnerability is that after a successful signature check the legit file can be overridden by the attacker through some HTTP shenanigans.
It's not 'Attack Vector: Network' in cvss, so it's probably scoring lower than a 7.
EDIT: With 'AV:Adjacent Network' and A 'User Interaction: Required' and max impact (High on Confidentiality, Integrity and Availability, assuming worst case), then it gets a score of 8.
The subjectives lower the severity to my eyes as well, including the use of HTTP mirrors (which is the default notwithstanding), and the attacker needing to be an existing mirror at the time of the announcement, which is already a vetted group (or be in the path between the user and the mirrors, umm that is quite possible though, but quite hard to target). And finally the window for the disclosure and attacks is almost null, someone needs to use apt to be vulnerable, but if they use apt, they are probably autoupdating apt itself, I wonder if a simple 'apt install thing' will trigger an apt upgrade, in order to patch those that are not running autoupgrades.
An here we see: The Debian people never introspect or change, because they were the first ones in open source, have too much power and outnumber the critics.
Sounds like the vulnerability is in the HTTP handling code, and because apt downloads packages over plain HTTP a man-in-the-middle position would be enough to exploit it.
It almost seems like a repeat of two previous apt vulnerabilities:
In 2019: https://lists.debian.org/debian-security-announce/2019/msg00...
And in 2014: https://lists.debian.org/debian-security-announce/2014/msg00...
I think the idea is that debian distributes the hash themselves through their domain, and mirrors offer the downloads either through http or https. So that you don't need to trust the mirror, you just verify the debian given hash. Only weakness would be a hash collision or a cve like this.
Is it going to be fixed for oldstable?
bookworm-security has the fix
Is there a German word for a broken tool that can only be fixed by using the same broken tool?
Of course, that breaks if implementation checks the signatures in wrong moment
If necessary, with instructions for downloading and verifying it out of band
Or maybe by passing a parameter to the old apt that disables the vulnerable HTTP download resumption when downloading the new apt
But yes, they could have mentioned this too to make the announcement at least half-assed
I didn't know that about apt, interesting choice!
EDIT: With 'AV:Adjacent Network' and A 'User Interaction: Required' and max impact (High on Confidentiality, Integrity and Availability, assuming worst case), then it gets a score of 8.
The subjectives lower the severity to my eyes as well, including the use of HTTP mirrors (which is the default notwithstanding), and the attacker needing to be an existing mirror at the time of the announcement, which is already a vetted group (or be in the path between the user and the mirrors, umm that is quite possible though, but quite hard to target). And finally the window for the disclosure and attacks is almost null, someone needs to use apt to be vulnerable, but if they use apt, they are probably autoupdating apt itself, I wonder if a simple 'apt install thing' will trigger an apt upgrade, in order to patch those that are not running autoupgrades.
How are you going to update if apt is compromised?
Download the package with your http client of choice, install with sudo dpkg --verify -i
Truth by flagging.