xz backdoor
The Xz Backdoor Highlights the Vulnerability of Open Source Software—and Its Strengths

Jason Koebler · Mar 30, 2024 at 3:27 PM

The backdoor highlights the politics, governance, and community management of an ecosystem exploited by massive tech companies and largely run by volunteers.

Image: Zulian Firmansyah, Unsplash

Friday afternoon, Andres Freund, a software developer at Microsoft, sent an email to a listserv of open source software developers with the subject line “backdoor in upstream xz/liblzma leading to ssh server compromise.” What Freund had stumbled upon was a malicious backdoor in xz Utils, a compression utility used in many major distributions of Linux, that increasingly seems like it was purposefully put there by a trusted maintainer of the open source project. The “xz backdoor” has quickly become one of the most important and most-discussed vulnerabilities in recent memory.

Ars Technica has a detailed writeup of the technical aspects of the backdoor, which intentionally interfered with SSH encryption, which is a security protocol that allows for secure connections over unsecured networks. The specific technical details are still being debated, but basically, a vulnerability was introduced into a very widely-used utility that chains into a type of encryption that is used by many important internet servers. Luckily, this specific backdoor seems like it was caught before it was introduced into the code of major Linux distributions.

Alex Stamos, the chief trust officer of SentinelOne and a lecturer at Stanford’s Internet Observatory called the discovery of this backdoor “the most interesting hack of the year.”

This is because the mechanism of the attack highlights both the strengths and weaknesses of open source software and the ecosystem under which open source software is developed, and the extent to which the internet and massive tech companies rely on an ecosystem that is largely run by volunteers.

In this case, the vulnerabilities were introduced by a coder who goes by the name Jia Tan (JiaT75 on GitHub) who was a “maintainer” of the xz Utils codebase, meaning they could make commits (update the software’s code) without oversight from others. Critically, Tan has been one of the maintainers of xz Utils for almost two years and also maintains other critical open source projects. This raises the possibility, of course, that they have always been a bad actor and could have been introducing vulnerabilities into earlier versions of xz Utils and other open source projects.

“Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system,” Freund wrote in his initial email.

The open source community is now doing a mix of collaborative damage control, soul searching, and infighting over the backdoor, how to respond to it, and what it means for the broader open source ecosystem. The xz backdoor was seemingly caught before it made its way into major Linux distributions, which hopefully means that there will not be widespread damage caused by the backdoor. But it is, at best, a close call that Freund himself said was essentially “accidentally” discovered.

This is all important because huge parts of the internet and software infrastructure rely on free and open source software that is often maintained by volunteer software developers. This has always been a controversial and complicated state of affairs, because big tech companies take this software, use it in their products, and make a lot of money from them. Many of these open source codebases are maintained by a small number of people doing it on a volunteer basis, and many of these projects have complicated politics about who is allowed to be a maintainer and how a project should be maintained and developed. If a trusted maintainer of a critical open source codebase is actually a malicious hacker, vulnerabilities could be introduced into widely used, critical software and chaos could ensue.

Stamos noted that the backdoor “proves what everybody suspected about the supply-chain risks of OSS. Should hopefully drive some serious investment by the companies that profit from open-source to look for back doors using scalable means.”

The backdoor highlights open source software’s strengths and its weaknesses in that, well, everything is happening in the open.

While a malicious maintainer can commit code that introduces a backdoor, the community can also actively analyze the code and trace exactly what was introduced, when it was introduced, who did it, and what the code does. The project can (and is) rolling back its codebase to an earlier distribution before the vulnerability was introduced. The coding history and email arguments of that user can be traced over time, and the broader developer community can make educated guesses about how this all happened. As I’m writing this, coders are analyzing Jia Tan’s contributions to other projects and the political discussions in listservs that led to them becoming a trusted maintainer in the first place.

On the open source software security listserv, developers are trying to make sense of what happened, and are debating about how and when the discovery of the vulnerability should have been made public (the discovery was made one day before it was distributed to the broader listserv). Tavis Ormandy, a very famous white hat hacker and security researcher who works for Google, wrote on the listserv, “I would have argued for immediately discussing this in the open.”

“We’re delaying everybody else’s ability to react,” he added. Others argued that making the vulnerability known immediately could have incentivized attackers to exploit the bug, or could have allowed others to do so. On Mastodon, software developers are criticizing Microsoft and GitHub for taking down some of the affected code repositories as people are trying to analyze it.

“Hey, it’s totally cool that Microsoft GitHub blocked access to one of the repositories in the very center of the xz backdoor saga,” Michal Woźniak, a white hat hacker who was part of a team that discovered DRM in a Polish train earlier this year wrote on Mastodon. “It’s not like a bunch of people are scrambling to try to make sense of all the right now, or that specific commits got linked to directly from media and blogposts and the like. Cool, cool.” Other coders mused that Copilot, a subscription AI coding assistant created by GitHub, could have integrated some of the malicious code into its training data.

All of this discussion and many of these issues are not normally possible when a vulnerability is discovered in closed source software, which is kept private by the company and whose governance is determined by the companies releasing a product. And that’s what makes all of this so interesting. Not only is vulnerability mitigation being managed in public, but so is the culture, politics, supply chain, and economics that governs this type of critically important software. About the author

Jason is a cofounder of 404 Media. He was previously the editor-in-chief of Motherboard. He loves the Freedom of Information Act and surfing.
More from Jason Koebler

  • WalnutLum@lemmy.ml
    link
    fedilink
    arrow-up
    4
    ·
    3 months ago

    I agree with this wholeheartedly,

    but if you feel about this methodology strongly you’re going to get hit with nay-sayers that use the same argument anti-VAT people use, as it’s ostensibly the same mechanism: that the developers farthest downstream would have to take the full amount of the percents piled up in their pricing scheme.

    • haui@lemmy.giftedmc.com
      link
      fedilink
      arrow-up
      9
      ·
      3 months ago

      Thanks but thats not what I meant. I was talking about a combined 1%. Like, if you used my work, you would need to donate at least (!) 1% of your total revenue to open source projects, ideally evenly distributed. That means the library further upstream would get a tiny amount but not nothing and if everyone did this, the library would have a million or more revenue streams (because libraries are widely used).

      • Auli@lemmy.ca
        link
        fedilink
        English
        arrow-up
        2
        ·
        3 months ago

        So would their salaries for people working on OSS contribute to that 1%?

        • haui@lemmy.giftedmc.com
          link
          fedilink
          arrow-up
          2
          ·
          3 months ago

          That could be the case. Thanks for asking and providing valuable new ideas. I think the amount of foss said employees get should factor in, yes.

      • TrumpetX@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 months ago

        This wouldn’t work for a few reasons, but the most glaring is that it would incentive re inventing the wheel.

        • haui@lemmy.giftedmc.com
          link
          fedilink
          arrow-up
          2
          ·
          3 months ago

          Which is exactly my idea. The AGPL is A LOT worse in this regard since it prevents them from going closed source in the first place iirc. I think many small businesses would gladly use the software and pay 1% of their revenue.

          This kind of argument imo is circular because if I build your house for free, you will not build it yourself, plain and simple. If I provide a service, I ought to get paid for it, plain and simple. And if you make money off of my work, you are part of the problem if you dont donate anyway. So making it mandatory imo is absolutely no issue.

          • TrumpetX@programming.dev
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 months ago

            Reinventing the wheel is exactly why we should use open source libraries.

            Expanding on other unintended outcome here: Different projects have different values. This takes no account for something like Spring vs Apache Commons IO. Or Rails vs nokogiri.

            Libraries will be incentivized into breaking apart to maximize revenue.

            This isn’t really unlike the unintended consequences of health insurance and how it leads to overpriced services with lots of indecipherable codes for service.

            It’s about how the system rewards (pays) for the service. I’m all for supporting open source, but the proposals in this thread are disturbingly anti open source.

            • haui@lemmy.giftedmc.com
              link
              fedilink
              arrow-up
              1
              ·
              3 months ago

              I have no idea what you are referring to. Feel free to provide a source.

              The consequences of our actions are for the most part completely oblivious until we try it, apart from starting wars and such. But even then its hard to say. So I respect your opinion but I disagree completely. Library maintainers have no reason to maintain libraries because they dont get paid or anything for it, which changes drastically once enough projects use my idea of a license.

              The health insurance you are referring to most likely is the american scam version where private companies can suck you dry as they want. Universal healthcare (what happens in some european countries) is what makes going to the doctor dirt cheap or completely cost free. The most disgusting pharma invenstions (like 1000x’ing a cancer medication that used to be dirt cheap iirc) are all american inventions.

              Thats the kicker. The system doesnt. They free load. Again, I respect your opinion. My idea is very much open source. It just enforces fairness. Thats all.