Debian apt security update (man-in-the-middle)
145 points by SG- a day ago | 30 comments
  • 8organicbits a day ago |
    I feel like they should release manual update instructions since the update mechanism is vulnerable. Although I see my systems already updated via unattended upgrades.

    edit: On lobste.rs I see a recommendation for `apt download`: https://lobste.rs/s/h7bvma/man_middle_arbitrary_code_executi...

    • xeyownt 17 hours ago |
      CVE says you need a non zero retries, so you can use Acquire::Retries=0 to avoid the issue completely (unless your packages were modified already of course).
  • thewisenerd a day ago |
  • justicz 21 hours ago |
    I found this! I posted a semi-click-bait-ey tweet about it here [0], I think it’s important for people know how easy these bugs are to find now. It’s becoming borderline irresponsible not to audit your internet-facing code with modern AI tools.

    [0] https://x.com/just1cz/status/2118009777922228361

    • justicz 21 hours ago |
      Speaking of which… if any of y’all work on security at OpenAI I have some questions for you about Daybreak! Please email me
      • guessmyname 10 hours ago |
        Every security engineer with access to Daybreak (Red or Blue) has a direct communication channel to OpenAI through an assigned Account Executive, or at least your employer does. If you are independent and authorized to use the model, your best option is to email/chat via the support page. The two Account Executives assigned to us are good people but not very technical, so I hope you have better luck with yours.
    • sczi 21 hours ago |
      Nice work! A similar vulnerability in 2019 also found by you included the recommendation to update with:

        apt -o Acquire::http::AllowRedirect=false update
  apt -o Acquire::http::AllowRedirect=false upgrade
      Since this also involves redirects, would that protect users while updating apt for this one also?
      • justicz 19 hours ago |
        That sounds right to me, but FYI the APT maintainers themselves are recommending Acquire::Retries=0 as the mitigation since some mirrors might actually have redirects.
    • DavCreator 20 hours ago |
    • vesinisa 19 hours ago |
      Looks like you also found a similarly critical apt bug in 2019: https://lists.debian.org/debian-security-announce/2019/msg00...

      Do you think there might be even more still lurking out there?

      And what is your take on HTTPS for apt? I assume the MitM scenario for this and the previous bug could have been avoided by the use of HTTPS by default?

      • justicz 19 hours ago |
        I do. I think that security-critical but overly complex software like this should be rewritten and certain aspects of it formally verified, since such things are now practical.
      • justicz 19 hours ago |
        HTTPS would have mitigated this particular bug but it feels like rearranging deck chairs on the titanic to fight over that right now. We need to audit everything with powerful AI like, yesterday.
        • solyin 19 hours ago |
          I'm sure Debian was invited to take part in Project Glasswing back at the beginning of this year.

          I wonder if all the people who laughed off Anthropic's sensationalistic claims about Mythos as marketing fluff have recanted, or if they're too busy patching, or maybe they're stochastically parroting Ed Zitron's latest blather.

    • nout 16 hours ago |
      This is also a reason why I'm trusting less and less the companies that strongly push against AI. Especially for SaaS type of businesses, AI red teaming is now a critical part of development process.
  • SoftTalker 21 hours ago |
    How would an attacker inject a redirect into an apt package download?
    • mikepurvis 21 hours ago |
      MITM on the network, I guess like DNS takeover or the like.

      So you pass through the upstream headers but then simulate a failure/resume and supply different contents for the resumed download.

      • SoftTalker 21 hours ago |
        So apt doesn't verify signatures on what is actually downloaded?
        • dinosaurdynasty 21 hours ago |
          > Improper file handling when resuming an HTTP download allows a man-in-the-middle attacker to replace a package after verification

          from the OP

          APT can use HTTPS, but often doesn't, making a MITM attack easier (also the idea for a long time has been signatures are enough, and/or TLS certs used to be a lot harder to get, but at this point you should really be using both).

          • SoftTalker 21 hours ago |
            Still doesn't make sense to me. So package A is downloaded, signature verified, then package B is downloaded, but somehow the package A file is replaced? Is it something like that?
            • tosti 20 hours ago |
              The somehow is package B has the same filename as package A.
            • xeyownt 18 hours ago |
              The bug is not trivial, I asked my AI friend to analyze.

              To summarize, APT may have several download sessions in parallel, which may download the same "resources". To save bandwidth, disk storage, these same resources are downloaded only one, but given different names on the disk through hard links.

              Because of HTTP retry, APT may be lured into downloading again a resource, but that was associated with a different package name, package that was already checked (hash verified). This is because of some differences between the package name / filename / URI, etc.

              Anyway, the point is that hash are verified when a package is completed, but because of possible parallel downloads and hard links usage, a verified package can be rewritten.

              What I find crazy though is that why packages are not first completely all downloaded, then every time a package is used, the hash be verified before being used. This would reduce even further the surface of attacks, and I don't care about any performance impact.

          • thayne 20 hours ago |
            Https doesn't help with this if the MitM is the apt mirror you are using.

            One reason http is still used is because you need an independent signature anyway since it is common to use mirrors that don't have the same level of trust as the debian maintainers

  • hollow-moe 21 hours ago |
    But how do I update apt if apt is untrustable until fixed ? Good ol' .deb scp'd in dpkg'd.
  • ChrisArchitect 21 hours ago |
  • linsomniac 19 hours ago |
    For those of you not familiar, apt-cacher-ultra is fairly new (~9 months old), and it can reduce your exposure to this. It uses a completely different mechanism for verifying signatures, and does validate signatures, so if your apt clients grab the packages from the cache, it shouldn't be open to this bug.

    The next version is going to include TLS and ACME support for the client->cache connection.

    https://github.com/linsomniac/apt-cacher-ultra

  • xeyownt 18 hours ago |
    We are living in times where I read first in HN what apticron is going to send me by mail.
  • getcrunk 17 hours ago |
    It always bothered me that apt didn’t use encryption, I know the issue here doesn’t boils down to that, but damn this sucks.

    Sure I can update, but how to check I want compromised? Will apt check the state of past/installed updates?