The exploit didn’t actually run on those distros, though. Only on deb/rpm targets. So, effectively, it was stopped before it hit production.

Tumbleweed is rpm-based, though maybe not so used in production

I hope Open Source maintainers and the big companies get the message -- they need to change the financial outlook of open source maintaining.

I think the message would more likely be "don't use open source and pay for closed source" than "give money to open source and cross your fingers that it does something".

Either way, it gives more jobs and $$$ to software developers in general. I'm fine with both :)

Just imagine how many more jobs will be created if every large company decides to roll their own stuffs. A lot are actually doing this, but not enough.

That is a tremendous amount of duplicated effort and it would be nice to be able to go and do something else with our skills and lives.

That just sounds like the broken window fallacy then. "It's good we have broken windows so the window makers have jobs".

It absolutely is. But we're all window makers, so our perspective is slightly different from general econ. ;)

To be fair, you also need software engineers to break the windows. It is in our best interest to break the windows.

Since that already happened, let's drink from the half-full bottle.

You should have more discretion with those ideas or disclose irony clearly, which I hope is the case here.

If that is the takeaway the industry takes from this, it will be a huge mistake. We are talking about this at all precisely because it was open source. Commercial closed source software can simply be assumed to be compromised. We know of enough instances of it happening that if you still have a knee-jerk "oh that sounds like a conspiracy theory" reaction to that claim, you need to recalibrate your conspiracy theory meter, quickly.

I mean Okta has shown us that paying for closed source does not imply higher quality or more secure software.

Also F5 or Citrix: some of their core security products had 90s-style C exploits and other signs of development practices well behind the times - roughly at the level of going to surgery and seeing your surgeon not washing their hands in the bathroom.

https://www.cisa.gov/guidance-addressing-citrix-netscaler-ad...

https://www.mandiant.com/resources/blog/session-hijacking-ci...

https://www.fortinet.com/blog/threat-research/defending-agai...

https://www.cisa.gov/news-events/cybersecurity-advisories/aa...

Yeah I'm not implying that's the way to go, but thinking since something open source was compromised that it will encourage businesses to donate is wishful thinking.

It might be riskier (because you'd have to identify yourself with government documents) to plant a backdoor in a similar way at a large, proprietary software vendor like Microsoft. But I don't know that it would be harder. And in the case of proprietary software there would not be nearly as much public scrutiny, and the scrutinizing public would have fewer resources for inspecting it.

Like Ivanti's Pulse VPN? Who hid a CentOS 6 in an appliance, unpatched, way past EoL?

You mean going for safe companies, like Microsoft? That were infiltrated for ages with solarwind, "without any changes to their source code"?

Yes, good example, a company they are likely already doing business with.

How would it have changed anything in this specific case?

This might solve the original author's issues, AND might also attract other people to do the job. The more people, the more eyes. It's definitely not a silver bullet, but I would be surprised that OSS maintainers are fine with the current financial arrangement, or lack of it.

Money itself doesn't necessarily cure mental health issues. I'm mean it usually doesn't hurt, but it's not like you can blend cash up into a smoothy and cure depression. (Yes, that's a South Park reference.)

Lack of money on the other hand can both cause mental issues and make dealing with them harder if not impossible.

The original xz maintainer stated that he delegated maintenance due to (then) current mental illness issues he was facing, not because of finances.

He mentioned mental illness and other issues. Those other issues could very well be financial. Financial issues also affect mental health.

My guess is that most Linux boxes that run sshd use an LTS distro, not one with rolling release. But I don’t know how to get any data on this.

Also, what about those that are not yet discovered?

shh

Arch, Gentoo and openSUSE Tumbleweed are hardly the world.

Arch and Gentoo were also not supported, although the code shipped, because the exploit explicitly checked for RPM- and deb-packaged distros.

Suse is RPM based, but don’t remember whether the check was for the utilities or another method — Suse uses zypper for package management, as opposed to yum/dnf on the far more popular RedHat-based distros, so it depends how the exploit checked.

The initial advisory (https://news.ycombinator.com/item?id=39865810) said it was:

  test "x$RPM_ARCH" = "xx86_64"

I heard that sshd in arc doesn’t link to xz

the link to xz was in systemd that then loaded sshd with the exploit in the shared libraries.

Only for distros that took a specific openssh patch (not merged in upstream openssh). Arch didn't afaik.

Arch and Gentoo are fairly popular as hobbyist distributions but they’re far less common in professional use, especially for the servers running SSH which this attack targeted. That doesn’t mean what happened is in any way okay but if this hadn’t been noticed long enough to make it into RHEL or Debian/Ubuntu stable you would be hearing about it in notifications from your bank, healthcare providers, etc. A pre-auth RCE would mean anyone who doesn’t have a tightly-restricted network and robust flow logging would struggle to say that they hadn’t been affected.

aye, this. RHEL is the industry standard and if you're not using that because you want Enterprise Support than you're using a derivative like Fedora, CentOS, or Rocky. Or else you hang out in the .deb side and use Debian or Ubuntu.

Arch is popular with a niche group of end users, but that ain't what most enterprise architectures are working on.

SLES is the only real alternative to RHEL for enterprises, also using RPM.

It doesn't seem to have been actually included in the Arch (binary) package but only because the backdoor build system itself didn't include the backdoor for Arch. If you cmp -l liblzma.so.5.6.1 between xz-5.6.1-1 and xz-5.6.1-2 there are only tiny differences. I'm guessing they didn't notice this before writing the advisory.

https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...

That’s because one of the first stages of the backdoor, that’s actually running at build time, checks if the distro is DEB or RPM based and aborts otherwise