102 pointsby SG-4 hours ago11 comments
  • linsomniac6 minutes 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

  • justicz3 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

    • vesinisaan hour 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?

      • justicz39 minutes 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.
      • justiczan hour 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.
    • sczi2 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?
      • justiczan hour 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.
    • justicz3 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
  • hollow-moe2 hours ago
    But how do I update apt if apt is untrustable until fixed ? Good ol' .deb scp'd in dpkg'd.
  • 8organicbits4 hours 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...

  • SoftTalker3 hours ago
    How would an attacker inject a redirect into an apt package download?
    • mikepurvis3 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.

      • SoftTalker2 hours ago
        So apt doesn't verify signatures on what is actually downloaded?
        • dinosaurdynasty2 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).

          • thaynean hour 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

          • SoftTalker2 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?
            • tostian hour ago
              The somehow is package B has the same filename as package A.
    • jxie20043 hours ago
      [flagged]
  • 3 hours ago
    undefined
  • kitehosting2 hours ago
    [flagged]
  • sick_of_slop2 hours ago
    [dead]
  • opengrass4 hours ago
    [flagged]
    • klez3 hours ago
      I'm pretty sure apt is written in C++. Am I remembering wrong?
      • Palomides3 hours ago
        parts of apt are being redone in rust, but anyway this seems to be a logic bug (in c++ code)