• u/lukmly013 💾 (lemmy.sdf.org)@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    62
    arrow-down
    13
    ·
    6 months ago

    Your Debian stable system is so ancient you got bigger vulnerabilities to worry about: Panik!

    Also the problem was that Debian’s sshd linked to liblzma for some systemd feature to work. This mod was done by Debian team.

    • Delilah (She/Her)@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      23
      ·
      6 months ago

      Even if you’re using debian 12 bookworm and are fully up to date, you’re still running [5.4.1].

      The only debian version actually shipping the vulnerable version of the package was sid, and being a canary for this kind of thing is what sid is for, which it’s users know perfectly well.

      • piefedderatedd@piefed.social
        link
        fedilink
        arrow-up
        0
        ·
        6 months ago

        There was a comment on Mastodon or Lemmy saying that the bad actor had been working with the project for two years so earlier versions may have malicious code as well already.

      • u/lukmly013 💾 (lemmy.sdf.org)@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        1
        ·
        6 months ago

        Mostly a joke about him calling it “ancient”, but there may be some unpatched vulnerabilities in older software. Though there could also be some new ones in newest versions.
        Still, unless it’s Alpha/Beta/RC, it’s probably better to keep it up-to-date.

  • recapitated@lemmy.world
    link
    fedilink
    arrow-up
    36
    ·
    6 months ago

    The xz infiltration is a proof of concept.

    Anyone who is comforted by the fact they’re not affected by a particular release is misguided. We just don’t yet know the ways in which we are thoroughly screwed.

    • BURN@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      This is a huge wake up call to OSS maintainers that they need to review code a lot more thoroughly. This is far from the last time we’re going to see this, and it probably wouldn’t have been caught if the attacker hadn’t been sloppy

  • mariusafa@lemmy.sdf.org
    link
    fedilink
    arrow-up
    27
    ·
    6 months ago

    That’s basically the idea of having a stable branch. Where all packages have 2+ years of testing and revisions.

    • jabjoe@feddit.uk
      link
      fedilink
      English
      arrow-up
      1
      ·
      6 months ago

      They are stagnant. They keep getting security/fix patches, just not new features.

  • oce 🐆@jlai.lu
    link
    fedilink
    arrow-up
    24
    ·
    edit-2
    6 months ago

    The malicious changes were submitted by JiaT75, one of the two main xz Utils developers with years of contributions to the project.

    “Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system,” Freund wrote. “Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the ‘fixes’” provided in recent updates. Those updates and fixes can be found here, here, here, and here. https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/

    That really sucks. This kind of thing can make people and companies lose trust in open source. I wonder if we will learn the reason behind that. I would guess the developer was paid a lot of money by some organization to risk ruining his reputation like that.

    • sep@lemmy.world
      link
      fedilink
      arrow-up
      22
      ·
      6 months ago

      Like the exact same thing can not happen in a closed source codebase. It probably does daily. Since closed codebases the due dilligence and reviews cost money, and nobody can see the state. They are intentionally neglected.
      Open source nor closed source is immune to the 5$ wrench hack

      • bier@feddit.nl
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        Exactly, if you are as big a Microsoft, you can’t tell 100% if one of your developer’s is actually being paid by a foreign government. Even if you say completely check the commits other devs make, there will still be deadlines when a code review is just “looks fine, next”.

    • Wooki@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      6 months ago

      No, its the exact opposite.

      Supply chain conpromise is a level of risk to manage not unique to FOSS. Ever heard of sunburst? It resulted in a lot of Microsofts cloud customers getting wreaked all because their supply chain was compromised.

      Do people continue to buy into 365 and Azure? Yes. Without care.

      So will this hurt open source projects? Not at all, in fact it will benefit them, highlight just why source code SHOULD be open source and visible to all! We would have had very little to no visibility and capability to monitor closed source. Let alone learn, improve and harden how projects can protect against this increasingly more common attack.

  • shotgun_crab@lemmy.world
    link
    fedilink
    arrow-up
    19
    ·
    edit-2
    6 months ago

    Still paniking, cause the backdoor was apparently targetting Debian servers, it was discovered just by chance and the “mantainer” made commits for 2 years in the same repo

      • dan@upvote.au
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        and it was only discovered accidentally, when someone was profiling some stuff, noticed SSH using a bit too much CPU power when receiving connections even for invalid usernames/passwords, and spent the time to investigate it more deeply. A lot of developers aren’t that attentive, and it could have easily snuck through.

    • TangledHyphae@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      6 months ago

      The slowness is on purpose? To help identify the sshd in question to the attacker which nodes are compromised? What reason(s) could there be?

      • getaway@lemmynsfw.com
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 months ago

        He’s talking about Debian’s slowness in getting new versions to stable, and how the meme ignores security backports.

  • Rodeo@lemmy.ca
    link
    fedilink
    arrow-up
    16
    ·
    6 months ago

    Panik: your Debian stable system is so ancient it still contains the heartbleed bug.

    • bruhduh@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      6 months ago

      Is linux 6.1 vulnerable to heartbleed? I’m on lmde6 with linux 6.1 btw) edit: as other comment said debian 12 is good so everything alright

        • Hello Hotel@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          edit-2
          6 months ago

          Its a CPU bug only the kernel can fix 🤒. The kernel is responsible for its running hardware.

          Am I dumb? that’s the spectere and meltdown bug. xz-utils malware is a whole other thing, lol.

            • Hello Hotel@lemmy.world
              link
              fedilink
              English
              arrow-up
              0
              ·
              6 months ago

              Clearly not, lol. Every vulnerability is spectere aparently. (To be fair, the other CVE this week is hardware based)

              • areyouevenreal@lemm.ee
                link
                fedilink
                arrow-up
                1
                ·
                6 months ago

                Heartbleed isn’t new either. It’s from years ago. It’s also unrelated to the xz backdoor. Maybe you should get some rest. Check your carbon monoxide alarms are working. If not see a doctor. It sounds like you are having memory issues.

      • Samueru@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        I recently ran into a bug in the latest version of cmake that breaks it completely in my system, can’t compile shit and it just does a coredump.

        What is worse is that I can’t even report the bug because I can’t get the registration email from the cmake gitlab. I checked the manjaro repos and their cmake version is 2 versions older than the one that has the bug that left me thinking for a while lol.

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      0
      ·
      6 months ago

      In this case the slower updates payed off. There are many things wrong with Manjaro but slower updates is not one of them.

      • redcalcium@lemmy.institute
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        6 months ago

        It’s not though, because the malicious release happened more than two weeks ago and manjaro had to fast track the patched xs from arch git repo. This is why manjaro should extend their delayed update policy to catch this kind of issue in the future (maybe 2 months instead of 2 weeks) /s

        • Possibly linux@lemmy.zip
          link
          fedilink
          English
          arrow-up
          1
          ·
          6 months ago

          They honestly should as it probably would fix a lot of issues. Then again, Manjaro is so broken that it probably doesn’t matter