Debian apt security update: man-in-the-middle arbitrary code execution
lists.debian.org
lists.debian.org
I never understood the insistence on using HTTP as a default for apt. Once HTTPS transport was available and tested (which took forever btw) then it should have become the default. Maybe this will spur some changes.
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.
The way packages are validated actually is through the same channel as you download the packages themselves from (IE your mirror), they just are signed with the Debian package signing key(ring), of which only a select few maintainers have authorized private keys for.
This does mean an adversary (whether a MITM if you're using HTTP or malicious operator on the mirror server itself) can technically serve you old versions of an (officially signed) package indefinitely and your package manager would be none the wiser, but otherwise this approach actually works quite well.
There's no sensible argument here.
Package size is unique enough that just seeing the size of the transfer will usually be enough to tell.
From the original disclosure: https://lists.debian.org/deity/2026/11/msg00005.html
For context, Ubuntu trusty and apt 1.0.1 is from 2014.
Exposing all of the internals of something to any and all MITM keeps on demonstrating how it's a dangerous idea.
Hopefully this example settles at least some of this pointless discussion.
Let's compare the extremely, extremely rare edge case of this with signed packages via Debian's keyring on the local box, vs all the bugs and issues with any code in the SSL layer. And of course, that the people most able to MITM, which are often 'state actors', likely have root certs by various means regardless.
I would be astonished if for example the NSA hadn't obtained the capacity to generate certs for MITM at the drop of a hat.
And regardless, without certificate pinning, MITM is a thing with SSL anyhow. There have been quite a few sketchy SSL providers over the years, there was a deep post about how hard Mozilla works, for all their other foibles, in trying to keep bad actors out of their accepted list.
Point is, SSL isn't actually that secure, has its own layers of bugs and issues, not enough people certificate pin, and so on.
It clearly doesn't. I guess we'll wait for the next RCE to learn our lesson.
> [...] vs all the bugs and issues with any code in the SSL layer.
You keep calling it SSL, that already makes me suspect that you have a few outdated preconceptions. Today you can use a formally proven TLS implementation, if you're so inclined. Formally proven APT? Will never happen.
If TLS is used, it significantly reduces the surface area exposed to anyone who can access or tamper with the traffic. None of the code that literally made an RCE possible would be accessible in the vast majority of cases.
Imagine if we would have had APT using TLS everywhere, by your own words the threat would have been "if NSA MiTMs you with the certificates they can generate". A huge difference in how exploitable this vulnerability would have been.
Of course, that breaks if implementation checks the signatures in wrong moment
Assuming transport is compromised and you can only trust package signatures IS A GOOD THING. Extra security layer on top of it is nice of course but arguably if it was all https we would've never found this bug and then in case of CA compromise attacker would have plenty of bugs to use to fool apt.
The problem is that they failed ordering of validation; it should be "download from source" (of any type, remember that http(s) isn't only way) -> put into temporary dir -> validate, regardless of source used.
There are also edge cases where HTTPS does hurt you, on system without reliable time (and there is quite a few SBCs that don't have RTC) you would just not be able to download the packages at all because all certs are in future.
But yes, it should probably be a Debian installer question: use HTTPS sources or not. Debian is the universal operating system but most users running a desktop or server setup should choose YES. The setups where you really want plain HTTP sources are an edge case and users setting up such systems probably already know about their special requirements, so HTTPS sources should really be presented as the default / "if in doubt" option.
Not something that should be the default, exposing everyone to the dangers.
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 HTTPS to make the announcement at least half-assed. Even just saying "good luck not getting exploited" would be an improvement over literally nothing
apt -o Acquire::Retries=0 update &&
apt -o Acquire::Retries=0 upgradeI think this demonstrates exactly why everything should be https.
A compromised mirror cannot serve packages that aren't properly signed.
This attack used an HTTP redirect to serve a backdoored package after the signature has been verified. I'm not sure that HTTP redirect attack would work with an HTTPS repository!?
Is it going to be fixed for oldstable?
bookworm-security has the fix
There's need if your apt client hits a redirector that redirects to a mirror close-by. That's the default for Kali Linux, so it's very much needed.
This being said Debian's default deb.debian.org is a CDN, so maybe disabling redirects by default in Debian, and letting downstream distros enable if if needed, might be a good idea.
However when you change a long-standing setting like that, hard to know in advance what will break...
And as others noted, mirror sysadmins might use redirects in their webserver config. So if you disable the setting, users that hit a mirror might face apt errors, that can be a lot of users impacted.
Is there a German word for a broken tool that can only be fixed by using the same broken tool?
Odd, I am not familiar with that that German word.
# apt -o 'Acquire::http::AllowRedirect=false' update
# apt -o 'Acquire::http::AllowRedirect=false' install apthttps://blog.packagecloud.io/attacks-against-gpg-signed-apt-...
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.
I always strongly argue against framing MITM scenarios as AV:Adjacent as MITM attacks can be performed at any point of the transmission path. If someone MITMs the package mirror the attacker is certainly not adjacent to the vulnerable component. I argue in favor of using Attack Complexity: High instead, as you do need to be in a MITM position.
And while UI:Required could be argued, there are also unattended upgrades and updates are performed regularly anyway. CVSS 4 makes some progress here with UI active vs passive, but ultimately CVSS is often not helpful for capturing the unique risk of a vulnerability.
1) Apt downloads first package (unmodified)
2) apt checks signature -> signature checked and remembered as valid
3) apt downloads second package, http redirect to the same url as package 1
4) the second package overwrite first one due to sharing URL. The temporary storage name or download cache key is derived from URL.
5) signature for package 2 fails but first one (already overwritten by bad one) is still considered good
6) Package 1 gets executed because the signature check already passed in step 2
Note sure where exactly resuming an HTTP download fits in. Maybe step 4 also requires pausing and resuming the update process. Which could involve some state serialization/deserialization vulnerable to conflicting URL confusion.
> APT can merge two different package downloads after an HTTP redirect gives them the same URI
It sounds like the verification is ran but there is some deduplication or caching involved keyed on the destination of the url redirect, not the original source.
So could imagine a malicious server that:
Responds for a request for foo.deb with a redirect to evil.deb containing the original foo.deb. This validates properly.
Responds with a second request for bar.deb with a redirect again to evil.deb that now returns a malicious package. The downloading code thinks it has already validated evil.deb