> It baffles me how such an important package that so many Linux servers use every day is unmaintained by the original author due to insufficient funds. Something gotta change in OSS. I think one solution could be in licenses that force companies/business of certain sizes to pay maintenance fees. One idea from the top of my head.
This just doesn't work. Fully open source software (as opposed to source available) is so much more useful than the alternative that there's always going to be an OSS fork for any sufficiently useful project. AFAICT Elasticsearch and Redis have not really "won" by their respective license changes but rather have just fragmented their own market and sown the eventual seeds of their destruction.
There ought to be streams of input funds.
Not easy to implement (which maintainers qualify for funds, etc) but should be looked into.
Every intelligence service in the world wants one or more. Many can hire truly bright programmers who will contribute to Linux over years, doing nothing nefarious at all, to build a trustworthy profile. and even contribute meaningful and positive features.
Then, maybe 2 of 3 trusted profiles make tiny changes as part of a much larger valid contribution. each one a tiny adjustment, each one not particularly interesting from a security point of view, unless you look at all 3 at the same time, and of course they were not added at the same time.
I am quite certain they have people who are working at Apple and Microsoft as well with the same mission.
How does one go about becoming a corporate plant? If the CIA offered me $1M to inject a back door into some shenanigans corporate product and told me it was being used to target Bashar al-Assad or cripple Russia’s war effort, would I do it? I don’t know honestly. Principles say it’s not right, but I wouldn’t blame someone (or myself) for saying yes.
Of course, being a data guy I’m probably not at risk of such a decision, since no one is injecting backdoors into corporate analytics. Dare to dream of a shadowy government payout I suppose.
Why would that "not be right"?
As this would only be like 10 lines of code, instead of linking a huge library that will in turn pull in another bunch of libs, it seems like it should reduce attack surface.
But since it's only a few lines of code most seem to think that unnecessary.
It should be noted that systemd actually fixed this a few days before the backdoor was pushed
https://github.com/systemd/systemd/pull/31550#issuecomment-1...
I'm not so sure what to think about the dlopen patch though. It obviously fixes this attack vector, but in general it makes it harder to discover dependencies in a simple way. I wish PE-style late binding would exist for ELF.
Luckily most users was unaffected unless they used a rolling release distro.
Finally, we still dont have a full analysis so its not known if systemd-enabled sshd is the only attack vector.
There is absolutely nothing that would suggest this hasn't happened before or will not happen again.
The only solution is to scope security relevant functions and add a multi stage formal verification process before freezing the commits. This assumes no collusion.
They do exist. Kept things exciting.
So yeah, congrats to everyone involved discovering this, excellent work, really! But how sure can we be, that there was no other successful attempt?
Makes me wonder whether it's time to reduce complexity and diversity in technology? Wouldn't it be beneficial to recreate everything from scratch(except maybe for machines producing hardware)? Leave one or two compression standards that are easy to understand and implement once and for ever. Maybe even aim to make them "finished" since the very beginning? So that they won't require changes after some time. I believe that recreating that and foundational things: compiler(of a language that is reinvented and standardized), OS components, web protocols and so on would be beneficial. There are so many of each and each can be vulnerable now or get vulnerable in the future. Many pitfalls aren't mentioned like why would we believe existing hardware producing new components to be trustworthy or how to make such a revolution without loosing so much progress, who will found it and how can it found commercial interest.
These are, of course, just murky dreams that linked book gave birth to, but there is no reason not to be paranoid.
The more worrying question is, what else was compromised by these kinds of people, and for how long?
There has been a lot of interesting analysis of the code, which has a feeling of the awe and sophistication of stuxnet yet on the scale of “this could be the work of a single motivated coder … like one of us”.
But what I haven’t found yet, and would like leads on, is what ther thinking is about the attack in a wider context…
What is the current thinking on:
1. Was the malicious code inserted by the new contributor, or was this likely a compromised account?
2. If the new contributor did it, did they become an xz maintainer with the aim of acting maliciously?
3. If the new contributor was malicious, why take so long to attack and why do it in xz? Or are they also attacking lots of other systems, perhaps under other names?
4. And what can we do about these attacks? How can we build a system that isn’t ultimately brought crashing down by one or two bad actors?
5. Small technical detail I haven’t spotted in writeups: was the attack commands signed in some way so only the attacker can use it and the world can go hunting for a smoking gun cert that matches the attacker?
First they need to gain some credibility. And they also need to obfuscate what they were trying to do. The payoff if they were to succeed is potentially enormous, so it makes sense to do things slowly.
> and why do it in xz?
xz is almost a perfect target- undermaintained, complicated code that isn't well understood by many people, deployed and used widely.
> Or are they also attacking lots of other systems, perhaps under other names?
The answer probably depends who the attacker(s) are, and what sort of funding or other motifivations they have. We can only guess.
> 4. And what can we do about these attacks?
This is a big unanswered question. I haven't seen any great suggestions yet. We were very lucky with this particular attack.
> How can we build a system that isn’t ultimately brought crashing down by one or two bad actors?
The complexity involved in this attack suggests that it was probably a group, IMO.
> 5. Small technical detail I haven’t spotted in writeups: was the attack commands signed in some way so only the attacker can use it and the world can go hunting for a smoking gun cert that matches the attacker?
Yes, sort of. Filippo's thread has a good description: https://bsky.app/profile/filippo.abyssdomain.expert/post/3ko...
Is no one asking if there was a state actor behind the contributor? My question is what was the ultimate end goal, and who motivated this exploit?
Certainly the worst of my career.
In terms of severity and nefarious intent, it's probably the worst that's happened.
It’s also unfortunate that the maintainer will be associated with the lack of judgement. But they will get through it. Probably time to pass the torch fully now though.
Thankfully this only effects Swoole users, not all of PHP.
Won’t stop state actors of course, just normal people (well ok there are only state actors from NK. And exiles)
But IMO the real “bad” here is that it calls into question the entire model of volunteer open source contribution, which underpins a crazy amount of the tech world. No easy answers there.
Run this:
dpkg -l | grep liblzma
# or
xz --version
But it is unlikely you will see that especially on LTS as they are using an older version. On Ubuntu 22.04 I get version "5.2.5"
Ubuntu 24.04 was about to be affected but they removed that version when the news broke.
Then consider defense-in-depth. If you have sshd exposed to the Internet, you could put it behind a VPN such as Tailscale (or pure WireGuard).
And FWIW: With our current knowledge, any LTS version of Ubuntu should not have been affected by this backdoor.