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,” an official with distributor OpenWall wrote in an advisory. “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.

On Thursday, someone using the developer’s name took to a developer site for Ubuntu to ask that the backdoored version 5.6.1 be incorporated into production versions because it fixed bugs that caused a tool known as Valgrind to malfunction.

“This could break build scripts and test pipelines that expect specific output from Valgrind in order to pass,” the person warned, from an account that was created the same day.

One of maintainers for Fedora said Friday that the same developer approached them in recent weeks to ask that Fedora 40, a beta release, incorporate one of the backdoored utility versions.

“We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added),” the Ubuntu maintainer said.

He has been part of the xz project for two years, adding all sorts of binary test files, and with this level of sophistication, we would be suspicious of even older versions of xz until proven otherwise.

  • RBG
    link
    fedilink
    English
    arrow-up
    16
    ·
    edit-2
    3 months ago

    As opposed to what? If you said “thats why you cannot trust any software blindly” it would have been not that wrong.

    • TheKMAP@lemmynsfw.com
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      10
      ·
      3 months ago

      Single point of failure on the lone maintainer of a popular package, vs having to hack an entire company like SolarWinds and make a backdoor that bypasses their entire SDLC. Which is harder?

      • Plopp@lemmy.world
        link
        fedilink
        English
        arrow-up
        9
        ·
        3 months ago

        A better way to compare the two would be a lone dev releasing open source software vs a lone dev releasing closed source. And a company releasing open source vs another company of the same size releasing closed source.

        • TheKMAP@lemmynsfw.com
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          2
          ·
          3 months ago

          SolarWinds had garbage infosec but you gotta admit the attack chain is much longer and more complex than “kidnap one guy”.

      • jj4211@lemmy.world
        link
        fedilink
        English
        arrow-up
        5
        ·
        3 months ago

        There’s plenty of closed source packages or components with a single actor ultimately accountable for it.

        Imagine a tester even bothering to open a bug that starting a session takes 500ms longer to start than it used to. Imagine what the development manager is going to do with that defect. Imagine a customer complaining about that and the answer the company will give. At best they might identify the problematic component then ask the sole maintainer to give the “working as designed” explanation, and that explanation won’t be held to scrutiny, because at that point it’s just a super minor performance complaint.

        No, closed source is every bit as susceptible, of not more so because management is constantly trying to make all those tech people stop wasting time on little stuff that doesn’t matter, and no one outside is allowed to volunteer their interest in investigating.

        • GreyEyedGhost@lemmy.ca
          link
          fedilink
          English
          arrow-up
          1
          ·
          3 months ago

          Checking time to login is more likely in the security sector than anywhere else. A number of vulnerabilities based on timing have been identified and removed in the past.