The Story Behind The XZ Backdoor Is Way More Fascinating Than It Should Be

from the the-long-con,-the-short-reveal dept

Every few years, it seems, we’re reminded of the incredible number of dependencies built into the software we all rely on. Remember kik? Or Chef Sugar? Or any number of similar situations? The xkcd comic on dependency is so well known for a reason.

Image

So, the backdoor that was discovered in xz utils a week and a half ago felt somewhat familiar in some ways. It was another case where there was a dependency that relied on basically one random dude keeping some code up to date.

But, in many important ways it was really different. I took a bit of time before writing about this, because so much time was spent last week by people trying to sort out the details, and I was a little afraid that it was too early to understand what had happened. However, by now it’s looking pretty clear.

xz Utlis is a data compression tool that’s found in nearly all versions of Linux. On Friday, March 29, Andres Freund sent an email to a security mailing list, laying out why he believed there was a backdoor built into it. In an interview with the NY Times, Freund reveals just how close we were to no one finding this:

The saga began earlier this year, when Mr. Freund was flying back from a visit to his parents in Germany. While reviewing a log of automated tests, he noticed a few error messages he didn’t recognize. He was jet-lagged, and the messages didn’t seem urgent, so he filed them away in his memory.

But a few weeks later, while running some more tests at home, he noticed that an application called SSH, which is used to log into computers remotely, was using more processing power than normal. He traced the issue to a set of data compression tools called xz Utils, and wondered if it was related to the earlier errors he’d seen.

So, because it was using slightly more processing power than normal, he started digging deeper.

In particular, he found that someone had planted malicious code in the latest versions of xz Utils. The code, known as a backdoor, would allow its creator to hijack a user’s SSH connection and secretly run their own code on that user’s machine.

And even then, he wasn’t really sure and hesitated:

At first, Mr. Freund doubted his own findings. Had he really discovered a backdoor in one of the world’s most heavily scrutinized open-source programs?

“It felt surreal,” he said. “There were moments where I was like, I must have just had a bad night of sleep and had some fever dreams.”

And that’s where the mystery got even deeper. Like lots of open source software, lots of people suggested changes, and starting in 2021 a user with the username “JiaT75,” known as Jia Tan, had been submitting code to various open source projects. In early 2023, they submitted to xz Utils.

Soon after that, what appears to be a sneaky social engineering scheme began. As described by Dan Goodin at Ars Technica, a bunch of random people started complaining that the long-term maintainer of xz was falling down on the job. This led others to suggest that perhaps they needed help and pointed to Jia Tan as a possible helper.

It would appear that this backdoor was years in the making. In 2021, someone with the username JiaT75 made their first known commit to an open source project. In retrospect, the change to the libarchive project is suspicious, because it replaced the safe_fprint funcion with a variant that has long been recognized as less secure. No one noticed at the time.

The following year, JiaT75 submitted a patch over the xz Utils mailing list, and, almost immediately, a never-before-seen participant named Jigar Kumar joined the discussion and argued that Lasse Collin, the longtime maintainer of xz Utils, hadn’t been updating the software often or fast enough. Kumar, with the support of Dennis Ens and several other people who had never had a presence on the list, pressured Collin to bring on an additional developer to maintain the project.

In January 2023, JiaT75 made their first commit to xz Utils. In the months following, JiaT75, who used the name Jia Tan, became increasingly involved in xz Utils affairs. For instance, Tan replaced Collins’ contact information with their own on oss-fuzz, a project that scans open source software for vulnerabilities that can be exploited. Tan also requested that oss-fuzz disable the ifunc function during testing, a change that prevented it from detecting the malicious changes Tan would soon make to xz Utils.

As Wired notes, this appears to be a slow burn operation, likely state sponsored, using the openness of open source technology, combined with the social engineering to slip in this very dangerous backdoor.

That inhumanly patient approach, along with the technical features and sophistication of the backdoor itself, has led many in the cybersecurity world to believe that Jia Tan must, in fact, be a handle operated by state-sponsored hackers—and very good ones. “This multiyear operation was very cunning, and the implanted backdoor is incredibly deceptive,” says Costin Raiu, who until last year served as the most senior researcher and head of the global research and analysis team at Russian cybersecurity firm Kaspersky. “I’d say this is a nation-state-backed group, one with long-term goals in mind that affords to invest into multiyear infiltration of open source projects.”

As for which nation, Raiu names the usual suspects: China, Russia, and North Korea. He says it’s still too early to know the true culprit. “One thing is for sure clear,” he adds. “This was more cunning than all previous software supply chain attacks I’ve seen.”

I’ve seen some suggest that this is why open source software is vulnerable, since this sort of attack can happen (and there are already some stories suggesting at least attempts elsewhere). But, of course, the fact that it’s open source software is also why the backdoor was discovered (and relatively quickly).

So, as it stands, it appears that a long con scam was under way. This scam allowed someone (or some agency) to get extra power over some random dependency found in most versions of Linux, through social engineering. That involved both submitting useful code to the utility over time, and then having a group of users complain that the existing maintainer was being too slow to fix things, and suggesting this one contributor who had been useful and had a multi-year track record.

Then, as that user gained more and more trust — and control —, they were eventually able to slip in a backdoor that had the potential to be massively dangerous. It was only stopped because one dude found that some process appeared to be running a bit slow.

As security expert Alex Stamos told the NY Times:

If it had gone undetected, Mr. Stamos said, the backdoor would have “given its creators a master key to any of the hundreds of millions of computers around the world that run SSH.” That key could have allowed them to steal private information, plant crippling malware, or cause major disruptions to infrastructure — all without being caught.

And, of course, it’s entirely possible that similar attacks have already been successful. However, after what was discovered by Freund over the last few weeks, and the collective hand-wringing in the open source and computer security worlds, it’s hopefully much more difficult for it to occur as people are now much more aware of this possible attack.

This isn’t a story of someone getting fed up or annoyed at how others were using their software, unlike those past stories about dependencies. Hopefully, we never have to find out just how disastrous this could have been by having a similar attack succeed (or at least not get caught this quickly).

Filed Under: , , ,

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “The Story Behind The XZ Backdoor Is Way More Fascinating Than It Should Be”

Subscribe: RSS Leave a comment
21 Comments
Anonymous Coward says:

“I’ve seen some suggest that this is why open source software is vulnerable, since this sort of attack can happen”

Was open source thought to be not vulnerable to this sort of attack? Not sure why but …

Certainly one is not claiming closed source is better due to not being vulnerable to this sort of attack?

This comment has been deemed insightful by the community.
Anonymous Coward says:

Re:

It took 3 years of (mostly part-time) work, and less than 2 weeks to find the backdoor (many thanks to that somebody devoted enough on this project), not enough for this code to reach the next major release.

In proprietary softwares, it’s often the inverse, and worse, some backdoors will never go public.

Now we’re supposed to learn right from wrong after the OpenSSL and Log4j messes but sadly it seems that understaffed team (or even one person team) of “popular” tools (I mean the kind of tool that could be used in billions of devices) is still a attack vector.

Let’s say that if any trillion dollar company would be obligated to give even 1M$ for every backdoor found in their product to critical open-source projects, a lot more developers would better sleep.

Anonymous Coward says:

Re:

Certainly one is not claiming closed source is better due to not being vulnerable to this sort of attack?

I’ve seen people implying it, anyway, but they’re naïve if they think people aren’t getting jobs at places such as Microsoft and Juniper to do exactly this. At such jobs, often only a few people see the code when it’s checked in; over the years, some more might see it, but I can tell you from experience that most people don’t ever pay much attention to the build system.

Anonymous Coward says:

Re:

Closed source doesn’t prevent bad actors popping open a copy of the software, examining its code, and using what they find, it only prevents others publishing exploits they find so they can be patched, making open source safer than closed source because exploits are publishable, and thus more fixable.

This comment has been deemed insightful by the community.
Anonymous Coward says:

From one XZ backdoor report post

Furthermore, an independent analysis of commit timings concludes that the perpetrator worked “Office Hours” in a UTC+02/03 timezone. It’s particularly notable that they worked through the Lunar New Year, and did not work on some notable Eastern European holidays, including Christmas and New Year. I have, however, been presented with a differing view, which you can read here.

That independent analysis describes that there was an effort to make it look like the work of China, but the signs point more towards Eastern Europe.

This comment has been deemed insightful by the community.
Thad (profile) says:

It really is an absolutely wild story. The complexity, the number of projects impacted (including convincing Google to disable a particular feature in a fuzzing tool that would have caught the exploit, and justifying it with a performance bug that the attacker almost certainly introduced themselves using a sockpuppet account), the length of time the con took.

This came really close to shipping with an Ubuntu LTS.

But on the other hand, it also came really close to shipping after a systemd update that would have closed the exploit.

This comment has been deemed insightful by the community.
Bruce Elrick says:

CPU usage

What I have not heard yet is whether the excess CPU usage that triggered Andres to dig deeper was necessary for the function of the backdoor or not.

That is, what if that CPU usage was poor coding on the part of the backdoor agents and, if they had been better at their job, might we not have learned about this until much too late?

Anonymous Coward says:

Re:

whether the excess CPU usage that triggered Andres to dig deeper was necessary for the function of the backdoor or not.

It was very likely not necessary. Apparently, the code checks a signature when someone’s trying to use the backdoor, which would necessitate some CPU usage. But to use a noticeable amount of CPU to do nothing seems like bad programming; it probably indicates a few hundred million superfluous instructions.

Ash says:

Re: Re:

From Andres Freund’s original security report:
” … the code appears to be parsing the symbol tables in memory. This is the quite slow step that made me look into the issue.
Notably liblzma’s symbols are resolved before many of the other libraries, including the symbols in the main sshd binary. This is important because symbols are resolved, the GOT gets remapped read-only thanks to -Wl,-z,relro. “

Kurt Steiniger says:

Re: Have a look at his X account

Andres Freund (Tech)
@AndresFreundTec
·
Mar 30
Replying to
@binitamshah
FWIW, I didn’t actually start looking due to the 500ms – I started looking when I saw failing ssh logins (by the usual automated attempts trying random user/password combinations) using a substantial amount of CPU. Only after that I noticed the slower logins.

Anonymous Coward says:

Citation for hijacking claim?

The code, known as a backdoor, would allow its creator to hijack a user’s SSH connection and secretly run their own code on that user’s machine.

Is there a citation for this claim? The Ars story (linked and quoted by Schneier) says “Anyone in possession of a predetermined encryption key could stash any code of their choice in an SSH login certificate, upload it, and execute it on the backdoored device.”

But where does the idea of hijacking connections come from? The threat models between these two claims differ significantly. In particular, hijacking implies the attack would only work if the user had a connection; presumably, that would be an authenticated one, and servers to which no users logged in during that time (or whose logins couldn’t be observed by the adversary) wouldn’t be vulnerable. With the Ars claim, all servers would be vulnerable whether they were used (legitimately) or not; an attacker could open their own connection for the attack.

Anonymous Coward says:

Re:

I think the direct answer to your comment is that the NY Times is not using “hijack” in any particular technical meaning, only in a colloquial one in which all of those things (and many more) would be broadly considered “hijacking.” Kevin Roose is a journalist not a security specialist or programmer, and he was writing to a general audience not a technically specialized one. And while Techdirt’s audience probably has a somewhat higher percentage of such specialized individuals, it’s still far more general than not.

More broadly as to the exploit in question, the answer right now is that testing and reverse-engineering is still ongoing, and nobody knows precisely how it is supposed to function yet.

We know that it is active in response to un-authenticated connection attempts to open ssh ports, which could mean that the attacker could authenticate a connection to any open port with the right certificate. Or that could be unintentional behavior.

It is rather less likely that it could arbitrarily open an ssh port itself. Though possible.

Eldakka (profile) says:

One of the things that really confuses me about this saga is:

a never-before-seen participant named Jigar Kumar joined the discussion … with the support of Dennis Ens and several other people who had never had a presence on the list, pressured Collin to bring on an additional developer to maintain the project.

How can some unknown randoms with no athority on anything apply pressure? To apply pressure you have to have some lever to pull. E.g., if these people had of been recognised maintainers of other core projects that use xz, e.g. Debian maintainers, kernel maintainers, well-known members of other distributions or core software (kernel, systemd, widely used DBs, Red Hat, etc.), people/organisations that apply funding (wiki foundation, Mozilla foundation, Apache) or provide you with funding, e.g. your boss at your day job, then, sure, they had levers to apply pressure with.

But some unknown randoms on the internet who have no history can’t apply pressure. They have no levers, no authority to rely on. The only levers they have are the ones you imagine in your own mind.

The correct response from Collin to Kumar, Ens, Tan was “Who the fuck are you? Fuck off, eat shit and die.”

Anonymous Coward says:

Re:

The only levers they have are the ones you imagine in your own mind.

That’s the same as in the other examples you gave, like “if these people had of been recognised maintainers of other core projects that use xz”. And, really, isn’t that always what “pressure” means?

So what if someone has software using xz? It’s Collin’s choice whether that fact carries significant weight or zero. Maybe end-users should be weighted higher, because they have less ability to do the work themselves. But that’s just, like, my (hypothetical) opinion.

The bigger problem, to me, is the notion that software needs to be updated with any particular frequency. If xz works, it hardly matters if nobody’s updated it for decades. I think Knuth had the right idea: TeX had been updated like 10 times over 45 years, with the changes being increasingly minor; it’s “done” until someone finds a bug.

This comment has been deemed insightful by the community.
Thad (profile) says:

Re:

Having someone complain about how you’re not doing enough and aren’t a good custodian of a project can be stressful, especially if you’re going through other stuff.

Pressuring someone to do something may be more effective if you have some kind of authority, but that doesn’t mean it’s not pressure if some rando does it.

Add Your Comment

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Ctrl-Alt-Speech

A weekly news podcast from
Mike Masnick & Ben Whitelaw

Subscribe now to Ctrl-Alt-Speech »
Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...