New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Backdoor in upstream xz/liblzma leading to SSH server compromise (openwall.com) (via Hacker News)
nullnothere
Member
in General
The original post:
https://www.openwall.com/lists/oss-security/2024/03/29/4
See: https://news.ycombinator.com/item?id=39865810
Debian stable seems OK and not affected but please check your own distros and also if you're specifically running any rolling releases and/or other updates.
Please read the thread and ensure that you are safe.
https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
https://lists.debian.org/debian-security-announce/2024/msg00057.html
I'm putting it out here to ensure it gets enough visibility for users. Anything SSH related is always something that needs serious and immediate attention.
Hopefully there aren't many folks who are affected.
Comments
If Debian is ok - everything is ok. Activate your disaster recovery plan. Good luck.
This is crazy.
It's an undoubtedly malicious, sophisticated backdoor that probably enables authentication bypass/remote code execution. The person who put in the backdoor has been involved in the project for over 2 years. Maybe there were other backdoors in the past.
Very criminal behavior. Interested to see how this will turn out.
Given the sophistication of the attack I doubt the attacker used real credentials. Wonder if any state agencies were involved (I love federal agents!).
Anyone have an ELI5 for non-technical folk?
Mount your ssh on wireguard, update packages and os, plan and move to debian.
Note: Debian sid affected
C projects like xz have massive, complex build/testing systems. The attacker, who was part of the project for 2 years, injected a malicious test file which was long undetected. The test modifies the build script of the project to include a backdoor. Xz is a very common compression library used by sshd, among others.
The backdoor was only found because a developer was tracking down performance issues caused by it.
The backdoor is strongly obfuscated. It overwrites/hooks several functions in sshd which are related to authentication. It's safe to assume the attacker is able to bypass authentication of affected systems.
What's scarier for most people though and should be strong reason for updating is that this backdoor has now been publicized. It won't be long until any script kiddie can run a public exploit from GitHub and root vulnerable systems.
TLDR: Update before it's too late!
There may be an issue with SSH that could potentially allow a backdoor (too early to tell what/how/when etc.). Patch/update your distribution to ensure that you're safe.
I strongly suspect that a government agency is involved in such a sophisticated attack.
And it also proves how easy it is to infiltrate open source libraries, all you have to do is fund people to become diligent contributors. Once trust has been earned, it's much simpler to get this kind of patch through.
The malicious actor contributed not onoy in liblzma, but also ither projects. It’s gonna be huge…
Is it just priv/pub key that they steal?
Jia Tan, who submitted the backdoor to Github, is the fucking maintainer of xz.
Flushing the whole thing right now.
Jia Tan committed. It was authored by two other individuals. "committed" just means that he applied/merged the patch.
This is supposedly the first commit related to it:
https://github.com/tukaani-project/xz/commit/ee44863ae88e377a5df10db007ba9bfadde3d314
I'm not saying that Jia Tan is innocent though. Perhaps they all conspired together. Funnily, Jia changed their SECURITY.md policy just 4 days ago to prefer reports over email (private) over GitHub security advisories, which perhaps more people have access to. Strange coincidence.
https://github.com/tukaani-project/xz/commit/af071ef7702debef4f1d324616a0137a5001c14c
Extremely common systemd L.
@matey0: I don't see other contributors to this commit: https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89#diff-e23c4ee4e2bf72b06ca17b08a69e54fef84e5fe19b3ff117a7d9566a798866b7
That's where
bad-3-corrupt_lzma2.xzis committed.The maintainer claims the container holds randomly generated data, but instead:
Okay, missed that. Yup, he was definitely involved.
Crazy, besides the literal maintainer they also had multiple malicious contributors. The co-conspirators can be seen urging distros to update to the malicious versions.
Theo de Raadt impersonation by ChatGPT
Oh, for the love of all things secure! Can you believe the sheer incompetence of those Linux fools? Yet another exploit, yet another glaring vulnerability, and yet again, they're left scrambling to patch up their shoddy excuse for an operating system. It's downright embarrassing!
How many times do we have to shout from the rooftops about the importance of security, about the meticulous attention to detail required to develop robust software? But no, they continue to parade around with their arrogance, their hubris, thinking they're invincible. Well, news flash: they're not!
Liblzma? More like libshambles! How many times do we have to witness this circus act of patching up holes in their sinking ship? It's a never-ending cycle of negligence and incompetence. And don't even get me started on their so-called development practices. It's like watching a bunch of toddlers playing with matches in a fireworks factory!
Meanwhile, here at OpenBSD, we prioritize security above all else. We sweat the small stuff, we dot every 'i' and cross every 't', because we understand the gravity of our responsibilities. We don't cut corners, we don't take shortcuts, and we certainly don't leave our users exposed to the whims of malicious actors.
So, go ahead, Linux fanboys, keep living in your fantasy world where security is an afterthought. But mark my words, the day of reckoning will come, and when it does, don't come crying to us for help. We'll be too busy enjoying the peace of mind that comes from knowing our systems are truly secure."
So the takeaway is that rolling releases are not a good idea(tm) and systemd broadens your attack surface? Did i get this right?
You are right about 1 thing: the State is the criminal.
Stable distributions have their own security issues due to slow updates. With web browsers for example, stable distros have practically given up on keeping up with security updates, instead recommending alternative packaging methods like AppImges or Nix.
This backdoor was only caught because of the massive slowdown it caused in sshd. Without these issues I wouldn't be surprised if it had survived many years.
Regarding systemd, generally yes. More dependencies = more possibilities for supply-chain attacks like these. Given how sophisticated and intelligently planned this attack was though they could've infested practically any other open source project in a similar manner.
I wonder how many more backdoors like this there are in the wild. I hope this news prompts security researchers to analyze build processes in other common libraries.
I highly doubt the security repositories would be noticeably slower on a high urgency patch than those of a rolling release.
Well at least Ubuntu/Debian seem to be able to follow ESR pretty closely on their official repos and normal releases have an unofficial repo that's also pretty tight in regards to releases. Sure, HoboLinux2k might have problems in this regard but big distributions probably not so much. Well, at least for Firefox that is. I've no clue in regards to Chrome and friends. Besides lets face it: Browsers will always be a security nightmare, even if massively locked down.
Sure, nothing is going to provide 100% safety but given Debian's stable releases are usually around for about 4 years + another ~4-6 before actually going EOL (at least something like that from the top of my head?) that's a lot of time vs. the mere days, weeks, maybe months of a rolling release. Bad timings might obviously still occur.
I was pretty much joking there. Systemd is still shit though
Probably quite a bit. This type of thing basically seems to more or less become a trend (and that basically means it'll have been this way for quite some time already).
Also testing
I vaguely remember reading something from a Debian package maintainer regarding firefox security issues so that's what I was going off of. Can't find the quote though and might be mixing something up.
Yup. I've heard about a bunch of incidents with nodejs libraries and similar but I think it's the first time I hear of a major core system library being affected.
I guess that's from back when Debian quit packaging normal Firefox releases and switched to ESR, which doesn't require that many updates to be pushed. Time flies...
Something interesting from that Ycombinator thread:
"A couple of years ago I wrote a Go library that wraps the xz C code and allows you to do xz compression in Go: https://github.com/jamespfennell/xz
About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though."
Followed by:
"I don't want to read too much into it, but the person (supposedly) submitting the PR seems to work at 1Password since December last year, as per his Linkedin. (And his Linkedin page has a link to the Github profile that made the PR)."
I sent a ticket to 1Password telling them they should investigate.
It's impressive how many months of preparation and effort have gone into getting to this point. It's pretty scary.
Not that I doubted that governments exploit undisclosed critical security flaws on a daily basis.
But the way they're introduced into the codebase here is pretty impressive.
Open source is a big attack vector, but it also means they can be found and fixed. It's better that way…
To deep dive:
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Such a payload is worth it, there might be many "dormant contributors" doing real and serious work waiting for their moment.
There are many possible places where to insert backdoors and there are many people waiting for the right moment.
The good thing is that with OSS these things are transparent. If this would have been closed source there would have been much harder to detect the problem AND the exploit would have lasted for much longer and only in the hands of "the right people".
Of course, I'm not questioning the open source model.
If there's malicious code in open source code, then there's a 100% probability that there's malicious code in proprietary software.
I'm not talking about telemetry crap, much more serious stuff.
And the probability of discovering them, on the other hand, is pretty low.
Incidentally, this was quickly discovered, so it's rather encouraging.
It only affected rolling release distributions.
That said, it's quite possible that others have been introduced before.
I hope we'll get to the bottom of this
repository of xz was disabled by GitHub.
https://github.com/tukaani-project/xz
Some more useful links and summaries:
Arch Linux Security Advisory ASA-202403-1: https://lists.archlinux.org/archives/list/[email protected]/thread/R3HBBSVYIRTXB4O64N2WZX55BF6IIPST/
https://lwn.net/Articles/967180/
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
https://nvd.nist.gov/vuln/detail/CVE-2024-3094
https://www.cve.org/CVERecord?id=CVE-2024-3094
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://xeiaso.net/notes/2024/xz-vuln/
https://www.theregister.com/2024/03/29/malicious_backdoor_xz/
https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094
That's a great writeup.
Regarding 1Password, it says:
"A pull request to a go library by a 1password employee is opened asking to upgrade the library to the vulnerable version, however, it was all unfortunate timing. 1Password reached out by email referring me to this comment, and everything seems to check out."