CGS wrote: >It seems there is additionally this outstanding bug: > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1151671
Yes. #1151671 makes clear that, even after a completed netinstall, which upgrades ca-certificates, the new installation retains revoked certificates, including eMudhra's trivially cracked certs. There is also #1142266[1], impacting Java certificates specifically, which is a related issue. That one also impacts upgrades from bookworm to trixie, and apparently remains unresolved since July 2026, when it was first reported. Both of these make matters far worse. And let's not forget that anyone using a browser on the installation media is using compromised certs. If someone looks up documentation while installing, which I assume is far from uncommon, any site they browse to can have its contents replaced via MITM attack. And they'd never know. Max Nikulin wrote: >monodev wrote: >>As stated elsewhere in the thread, apparently the installer is not >>affected by CVE-2026-109518 due to not using apt during the >>bootstrapping process, and by the time apt can be used it is already >>upgraded to the latest and secure version. > >I am in doubts if it is really so, that is why I raised the question >again. I suspect, Andrew oversimplified writing that response. He did oversimplify. He noted in his initial reply to me in this thread[2] that the upgrade process during netinstall utilizes unattended-upgrades. That utilizes APT internally. CVE-2026-109518[3][4] makes clear that HTTP redirection via the Retries mechanism bypasses PGP signature verification of packages installed with APT. HTTPS is, up to a point, a mitigation. Even still, it's not a *full* mitigation. The mirror itself can still ship malicious packages; and if you don't run the upgrade with `-o Acquire::Retries=0` set, you'd never know, since the PGP signatures of the packages will never be verified. This is why Ubuntu's mitigation instructions[5] advise *all* users to apply that flag to their upgrade, even if using an HTTPS mirror: >While enabling TLS provides protection against this particular vulnerability >when exploited by an on-path attacker, we strongly recommend that you install >the security updates, as described in the following section. >… >Temporarily setting Acquire::Retries to zero while installing this security >update provides a mitigation against this vulnerability, whether exploited by >an on-path attacker or a potentially malicious mirror. The phrase "or a potentially malicious mirror" is critical. Max Nikulin wrote: >To avoid ambiguity, images >debian-13.7.0-amd64-netinst.iso 2026-09-12 >were built before ca-certificates update due to the eMudhra case (DSA >6572-1) ><https://lists.debian.org/msgid-search/[email protected]> Precisely. So in the case of new installations, even HTTPS is not a mitigation. The first time unattended-upgrades runs—which happens during the installation process in the case of netinstall—both the mirror *and* your ISP can trivially MITM the upgrade. That's why I initially described the "coffee shop skid" attack vector, but per Andrew's initial reply to me, aside from those who use the offline installer, that's far less likely than an ISP or, as I noted, a mirror. Andrew M.A. Cater wrote: >The next point release is scheduled in under 14 days and will incorporate >all security fixes to the point of freeze prior to release at that point. >*That* release will have the fixed apt Right. But why hasn't an emergency point release been a priority? An incredibly similar vulnerability, CVE-2019-3462[6], likewise involving HTTP redirection, likewise totally bypassing PGP signature verification, occurred in 2019. An emergency point release[7] was made one day after the vuln was announced, with exactly one thing upgraded: APT: >The Debian project is pleased to announce the seventh update of its stable >distribution Debian 9 (codename *"stretch"*)This point release incorporates >the recent security update for APT, in order to help ensure that new >installations of stretch are not vulnerable. No other updates are included. How hard can it possibly be to get an emergency point release out the door with an update to APT *and nothing else*? Why is the point release team acting like there's a release cadence that is never deviated from, for any reason? This should have been as simple as updating ca-certificates following the eMudhra compromise, and again, to APT following the announcement of CVE-2026-109518. Emergency point releases were surely warranted in both cases, and clearly have been issued in the past following the disclosure of similarly critical vulnerabilities. In addition: In that case, Debian provided full mitigation instructions for upgrades of existing installations as part of their announcement of the vulnerability. As I noted in my initial email, the "mitigation" instructions in this case seem to be, by virtue of their absence, "Upgrade as usual. Nothing to see here! See? We secured your operating system for you!"—all while completely ignoring the possibility of a compromised mirror. I suspect some users are still using HTTP mirrors, unfortunately, and of course the number of potential attack vectors is much higher in that case. And that's setting aside the fact that the similarity between CVE-2019-3462 and CVE-2026-109518 is incredibly disturbing. Why was it considered reasonable to increase the default value of `Acquire::Retries` from 0 to 3 at any point in time? Why was convenience prioritized over security, especially given a historical critical vulnerability relating to HTTP redirection? At this point, my reaction to this vuln itself, as well as how it's been "mitigated", is essentially: >My little package manager can't possibly be this ōbaka! S2: It actually is?? [8][9] [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142266 [2]: https://lists.debian.org/debian-user/2026/11/msg00070.html [3]: https://security-tracker.debian.org/tracker/CVE-2026-109518 [4]: https://ubuntu.com/security/CVE-2026-109518 [5]: https://ubuntu.com/blog/apt-vulnerability-fixes-available [6]: https://lists.debian.org/debian-security-announce/2019/msg00010.html [7]: https://web.archive.org/web/20191222003344/https://www.debian.org/News/2019/20190123 [8]: https://en.wikipedia.org/wiki/My_Little_Sister_Can%27t_Possibly_be_This_Cute [9]: https://web.archive.org/web/20261003040737/https://i.kym-cdn.com/photos/images/newsfeed/001/430/297/773.jpg Yours in freedom, Elven Inquisition P.S. Given discussion elsewhere on the thread about who was/wasn't subscribed to the list, I added back the email addresses of those (indirectly) referenced by the thread. I wasn't subscribed when I posted, and I hadn't expected to be dropped. I'm subscribed now, though.
