Malicious code planted in xz Utils has been circulating for more than a month.

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.

  • AutoTL;DR@lemmings.worldBEnglish
    0·
    3 months ago

    This is the best summary I could come up with:

    Researchers have found a malicious backdoor in a compression tool that made its way into widely used Linux distributions, including those from Red Hat and Debian.

    An update the following day included a malicious install script that injected itself into functions used by sshd, the binary file that makes SSH work.

    So-called GIT code available in repositories aren’t affected, although they do contain second-stage artifacts allowing the injection during the build time.

    In the event the obfuscated code introduced on February 23 is present, the artifacts in the GIT version allow the backdoor to operate.

    “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.

    The malicious versions, researchers said, intentionally interfere with authentication performed by SSH, a commonly used protocol for connecting remotely to systems.

    The original article contains 810 words, the summary contains 146 words. Saved 82%. I’m a bot and I’m open source!

    • Aatube@kbin.melroy.org
      0·
      3 months ago

      So-called GIT code available in repositories aren’t affected

      I wonder what convinced the model to treat git as an acronym

  • Technus@lemmy.zipEnglish
    0·
    3 months ago

    The backdoor appears to specifically target RSA public key authentication, so they must have had a target in mind that they know uses RSA keys.

    • subtext@lemmy.worldEnglish
      0·
      3 months ago

      Would another less complex answer simply be that many (most?) people and organizations use RSA because it was first and elliptic signing is not yet as prevalent?

      Going with Occam’s Razor here…

  • DAMunzy@lemmy.dbzer0.comEnglish
    0·
    3 months ago

    A stable release of Arch Linux is also affected. That distribution, however, isn’t used in production systems.

    Shots fired!

    It seems WSL Ubuntu and Kali are safe with versions 5.2.5 and 5.4.4 installed respectfully.

  • Flying Squid@lemmy.worldEnglish
    0·
    3 months ago

    Please help me as a novice Linux user- is this something that comes preinstalled with Mint Cinnamon? And if so, what can I do about it?

  • uis@lemm.eeEnglish
    0·
    3 months ago

    Technically it breaks libsystemd encryption, which is not used in upstream openssh. There are unofficial redhat patches that use this library instead of reading one enviroment variable and writing to one file.

  • Aatube@kbin.melroy.org
    0·
    3 months ago

    openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.

    • uis@lemm.eeEnglish
      0·
      3 months ago

      Had redhat’s patch write READY=1 into $NOTIFY_SOCKET instead linking to libsystemd to do this, this backdoor would not be possible.

  • fmstrat@lemmy.nowsci.comEnglish
    0·
    3 months ago

    There are no known reports of those versions being incorporated into any production releases for major Linux distributions

    …

    A stable release of Arch Linux is also affected.

    … BTW.

    • liara@lemm.eeEnglish
      0·
      3 months ago

      The malicious code is only thought to have affected deb/rpm packaging (i.e the backdoor only included itself with those packaging methods). Additionally, arch doesn’t link ssh against liblzma which means this specific vulnerability wasn’t applicable to arch. Arch may have still been vulnerable in other ways, but this specific vulnerability targeted deb/rpm distros