- cross-posted to:
- privacy@lemmy.ml
- cross-posted to:
- privacy@lemmy.ml
The malicious changes were submitted by JiaT75, one of the two main xz Utils developers with years of contributions to the project.
“Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system,” an official with distributor OpenWall wrote in an advisory. “Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the ‘fixes’” provided in recent updates. Those updates and fixes can be found here, here, here, and here.
On Thursday, someone using the developer’s name took to a developer site for Ubuntu to ask that the backdoored version 5.6.1 be incorporated into production versions because it fixed bugs that caused a tool known as Valgrind to malfunction.
“This could break build scripts and test pipelines that expect specific output from Valgrind in order to pass,” the person warned, from an account that was created the same day.
One of maintainers for Fedora said Friday that the same developer approached them in recent weeks to ask that Fedora 40, a beta release, incorporate one of the backdoored utility versions.
“We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added),” the Ubuntu maintainer said.
He has been part of the xz project for two years, adding all sorts of binary test files, and with this level of sophistication, we would be suspicious of even older versions of xz until proven otherwise.
You must log in or # to comment.
openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.
Had redhat’s patch write
READY=1into $NOTIFY_SOCKET instead linking to libsystemd to do this, this backdoor would not be possible.It’s all systemds fault, got it.
Do it all? Then you did it all, motherfucker.
Thankfully this was discovered before hitting stable distros but I’m hoping it increases scrutiny across the board. We dodged a bullet on this one.
Across the board indeed. Scrutiny in code is one thing, where this story, as far as is known right now, really went south is the abuse of a trusted, but vulnerable, member of the community.
I know the (negative) spotlight is targeting Jia Tan right now (and who knows if they (still) exist), but I really hope Larhzu is doing okay. Who’s name is mentioned in the same articles.
Mental health is a serious issue, that, if you read the back story, is easily ignored or abused. And it wasn’t an unknown in this story. Don’t only check the code, check up on your people too.
He was likely a planted russian or china man who created some reputation before doing his master’s bidding.
This is why I run debian oldstable.
Or maybe it’s because I’m too lazy to do a dist-upgrade.
The backdoor has existed for a month at least. Yikes.
Long game supply chain attacks, pretty much going to be state actors. And I wouldn’t chalk it up to the usual malicious ones like China and Russia. This could be the NSA just as easily.
I think you are greatly underestimating FSB incompetense.
I honestly think the NSA has changed. If you look at the known backdoors they haven’t got caught making any new backdoors since like 2010. Their MO also seems to be more hardware and encryption (more of an observational charter) than manipulation.
There’s also evidence US Congress acted to stop the NSA from doing these underhanded tacits at least once https://www.wired.com/story/nsa-backdoors-closed/
They’re not idiots, lots of smart people there that surely understand the risk of something like this to US national security interests. It’s not the NSA that’s been asking for encryption to be broken in recent years. They’ve been warning about quantum threats and … from what I’m aware of actually been taking on the defensive role they were conducted to perform https://gizmodo.com/nsa-plans-to-act-now-to-ensure-quantum-computers-cant-b-1757038212
This seems like something that could actually be weaponized against predominantly western technology companies so I’d be very surprised if it was them and very surprised if they used someone that appears to be a Chinese born resident to do it.
It’s not the NSA that’s been asking for encryption to be broken in recent years.
I remember 2013 backdoored crypto by NSA. If they get caught less doesn’t mean they make less backdoors.
EIDT: it was discovered in 2007 and revoked as standard in 2014
Also they owned corporation that made backdoored crypto algos till 2018
That’s not true, Shadow broker leaks for example contained 0-day found by the NSA well after 2010. And that’s only what got published, there’s probably more !
There is a difference from finding something you can take advantage of and putting it there though, no? This sounds like the former.
But still, it’s a good point, thanks.
Ah sorry, english is not my native language so I’m not sure I fully got what you meant, your point was that they stopped inserting backdoors and instead concentrated on getting access by finding vulnerabilities ?
Basically two points, they stopped inserting backdoors and their backdoors seem to have only ever been to show them what’s going on (so this just doesn’t look like them to me).
I didn’t really comment on “what they do now” as much. I think they do continue to spy, finding preexisting vulnerabilities is definitely one way to spy. I wouldn’t be surprised if they report the worst ones in NATO systems to be repaired and keep the others for themselves.
They also tap into weak points like Google and Apple’s notification services where things aren’t end to end encrypted to gather information. I believe this was revealed recently.
Snowden I recall saying the modern NSA is more interested in metadata than what’s actually in the message as well.
In general, I think they still do some shady stuff, but I don’t think they do shady stuff that risks compromising a system. This exploit is quite literally a system compromise as (if I understand it correctly) it allows bypassing sshd authentication.
I really can’t believe they’ve stopped. Their mentality is “national security has no morals”. They’ll do everything they can do to facilitate that mission, though not getting caught is a big part of the facade they need to put on to keep or renovate their image to do this.
Maybe they’re being more careful, and doing simple things like putting in timestamps that emulate working hours in other timezones are certainly the first thing they’re going to think about. That one has always cracked me up, security researchers point to it like it’s proof of something, which is ridiculous. Just like our people are smart, I don’t think the foreign actors are dumb either.
And before you say it, I’d be all over not being paranoid if it hadn’t been proven to me time and again that these agencies won’t change, that they don’t give a shit about what’s right if it gets in the way of their mandate. The only thing that might change is how well they hide things now and intimidate their people into staying quiet. Because potential whistleblowers have seen the examples that have been made.
Personally I suspect they’re getting all the information they care about via subpoenas on big data and social media companies. They don’t have a need to compromise security on a technical level anymore because the justice system itself is compromised. That means backdoors only benefit national enemies at this point, so the NSA of today would rather those not exist at all.
Of course that’s not to say anyone should trust those agencies at their word on anything.
Backdoors at a mation-state level are a double edged sword. In order to successfully implement a backdoor, you need to ensure that you are more clever than your adversaries, because those same backdoors can be used against you. You must assume that they will eventually discover them, and be able to leverage them against you. Then you must be able to identify that it had been compromised, and then “responsibly disclose” the vulnerability before too much damage is done.
Much better to be on the defensive. Discover 0days first, either accidental or intentional, and then use them until someone else discloses them and they get patched to hell.
In order to successfully implement a backdoor, you need to ensure that you are more clever than your adversaries, because those same backdoors can be used against you.
In this instance, that’s not the case. Only those in possession of the right key can use the backdoor. Also, discovering infected systems from the outside, appears to be impossible - the backdoor simply does not do anything to reveal itself if you don’t have the key.
I must be mistaken then. I suppose keys have never, ever been compromised. Nobody has ever taken sensitive information without authorization, either. Especially not from the NSA!
You were talking about adversaries discovering the backdoor. That’s something entirely different from compromised keys. So your sacrasm is quite misplaced here.
If you throw enough money at the right person you can get shit done.
I don’t know man. Imagine you could have ssh access to every Debian and fedora server on the planet, and all you had to do was write tests for some compression library for 2 years and sneak in a clever patch. I’d guess such an exploit is worth millions. You wouldn’t work 2 years for millions of dollars?
This is sophisticated but it doesn’t have to be a state actor.
Who wants to bet he received a nice lump sum deposit of cash from a five eyes state to make an “accident”…
No…
Just read the story…
This is the best summary I could come up with:
Researchers have found a malicious backdoor in a compression tool that made its way into widely used Linux distributions, including those from Red Hat and Debian.
An update the following day included a malicious install script that injected itself into functions used by sshd, the binary file that makes SSH work.
So-called GIT code available in repositories aren’t affected, although they do contain second-stage artifacts allowing the injection during the build time.
In the event the obfuscated code introduced on February 23 is present, the artifacts in the GIT version allow the backdoor to operate.
“This could break build scripts and test pipelines that expect specific output from Valgrind in order to pass,” the person warned, from an account that was created the same day.
The malicious versions, researchers said, intentionally interfere with authentication performed by SSH, a commonly used protocol for connecting remotely to systems.
The original article contains 810 words, the summary contains 146 words. Saved 82%. I’m a bot and I’m open source!
So-called GIT code available in repositories aren’t affected
I wonder what convinced the model to treat git as an acronym
I imagine many aren’t familiar with British slang and therefore assume git must stand for something
It was like that in the original article. Or are you saying that the original was written by an AI too (it might be).
Please help me as a novice Linux user- is this something that comes preinstalled with Mint Cinnamon? And if so, what can I do about it?
You’re good. Even if you do use xz and ssh the version with the vulnerability only made it’s way to rolling release distros or beta version of distros like fedora 40
Thanks!
Welp, time to go check my version of fedora
made its* way to
As the other person said it’s likely that
xzis already installed on your system, but almost certainly a much older version than the compromised one. It’s likely that no action is required on your part assuming you’ve not been downloading tarballs of bleeding edge software.As the other person said, just keep doing updates as soon Mint recommends them (since it’s based on Ubuntu LTS, it’s a lot less likely to have these bleeding edge vulnerabilities).
Much appreciated, thank you.
The library itself is very common and used by a lot of things (in this case it seems that the payload only activated when used by specific programs, like SSH).
What you can do about it is keep your system up-to-date using your distribution update mechanisms. This kind of thing, when found out, is usually fixed quickly in security updates. In Mint (which I don’t use, but I believe is based on either debian or ubuntu, which uses dpkg/apt) security updates are flagged differently anc can be installed automatically, depending on your configuration.
tl;dr: keep your system up-to-date, it will keep known vulnerabilities away as much as it can;
In this case though the backdoor was added recently so updating could do the opposite of help here. Luckily I don’t think any stable distros added the new version.
It was added recently, but at this point in the timeline, fixes are available for most mainstream distro at least. Except for rare cases where a fix can’t be made available quickly, this kind of publicity is only done when a fix is broadly available. There are extreme cases of course, but in this case, it’s fixed.
Thanks. I do my best to regularly update, so here’s hoping it will not be a problem for me before an update fixes it!
Alternatively, if you never use ssh, then it wouldn’t be a problem.
There are definitely times where (at least based on the instructions I read) that I have had to use ssh for various reasons, so I think it will be a problem in the future if I don’t get a fix in an update. But I’m guessing a fix will be coming soon.
dpkg --list | grep xz
should return what version of xz package is on your system. Likely 5.4, in which case you should be okay.
ii xz-utils 5.2.5-2ubuntu1 amd64 XZ-format compression utilities On my latest Mint install.
which isn’t an effected version, so you should be okay.
It says “5.2.5-2ubuntu1.” So I’ll have to see about updating it.
EDIT: However, this says I should be safe: https://forums.linuxmint.com/viewtopic.php?t=416756
The affected versions are 5.6.0 to 5.6.1
Dude seems like a foreign asset
Jia Tan, University of Hong Kong in China. He’s been the sole maintainer of the package for almost two years.
It would make more sense to compromise developers in trusted positions, or steal their credentials, than going through the time and effort of building trusted users and projects only to burn them with easily spotted vulnerabilities.
This wasn’t easily spotted. They use words like sloppy, but it all started with someone digging in because starting ssh season was about a half second slower that it used to be. I could easily imagine 99.99% of people shrugging and deciding just something in the chain of session startup took a bit longer for a reason not worth digging into.
Also, this was a maintainer that just started two years ago. xz is much older than that, just he took over.
Looks like he’d done a lot for various US companies on his LinkedIn.
I would not be surprised if he was previously legit but pressured into doing this by the CCP.
Maybe he wasn’t sloppy by accident if he was indeed coerced by someone. I don’t think we’ll ever find out the backstory of this though.
I’ve watched a rundown of what the backdoor does. It’s impossible that this was an accident. It hides a compiled library in test data and injects that into the ssh binary to override code there.
They didn’t mean the backdoor was (or was not) an accident. They meant the backdoor was implemented sloppily enough to be discovered and maybe that was not an accident (as in, he wanted it to be found, but still wanted to plausibly be seen as trying his best to keep those coercing him appeased)
foreign to whom?
his mother. he hasn’t called in a week, he doesn’t write.
Maybe she’s a bitch.
The backdoor appears to specifically target RSA public key authentication, so they must have had a target in mind that they know uses RSA keys.
Would another less complex answer simply be that many (most?) people and organizations use RSA because it was first and elliptic signing is not yet as prevalent?
Going with Occam’s Razor here…
Woosh? (Probably)
I genuinely don’t understand if I missed something here, and would love more explanation.
I’m assuming the original post you replied to was meant to be a joke.
It’s the 46 upvotes that have me concerned that many people do not in fact see it as a joke
I would highly recommend Curve25519, etc., just because such keys are faster and less common than RSA public-private keys in today’s world. RSA 2048-bit keys are considered weak today, while the Curve25519 256-bit keys remain stronger. Also, the ChaCha20-Poly1305 cipher has an interesting backstory and doesn’t necessarily need hardware acceleration (which, in theory, could be borked by the HW-vendor) to obtain good performance.
Unfortunately, some SSH front-ends don’t play nice with Curve25519 public-private keys yet… (I’m pointing at the putty SSH client, but that may have improved from the last time I had to use it)
It would be Ed25519 for SSH:
$ ssh-keygen -t ed25519
A stable release of Arch Linux is also affected. That distribution, however, isn’t used in production systems.
Shots fired!
It seems WSL Ubuntu and Kali are safe with versions 5.2.5 and 5.4.4 installed respectfully.
I think the AI that wrote the article misunderstood.
Arch doesn’t build from release tar balls, but straight from git. Arch also doesn’t link sshd against liblzma. So while they’ve shipped the dirty version of xz utils, at least sshd is not affected.
It’s possible that the dirty version affected some of the other things that link liblzma. Like a handful of kde components for example.
Arch didn’t build from git until March 28th. See commit history for xz and lib32-xz packages.
Also, the malicious code only activated if it detected being built as dpkg or rpm.
the AI that wrote the article
The linked article is by Dan Goodin from Ars Technica. He’s not immune to mistakes, but he’s been writing good articles about security for years.
Can we please not accuse everybody of being AI just because they made a mistake?
Well, he’s credited as the editor overseeing security stuff. Reading between the lines I’d say he’s just taking responsibility for the articles correctness.
This article in particular is just so poorly written that you’d forgive me for assuming it wasn’t man-written.
Can we please not accuse everybody of being AI
Suspicious. /s
Don’t forget about openSUSE Tumbleweed! It’s actually affected AFAIK.
Damn, I installed mine disrespectful.
Technically it breaks libsystemd encryption, which is not used in upstream openssh. There are unofficial redhat patches that use this library instead of reading one enviroment variable and writing to one file.
Here is a more detailed FAQ about what happened:
This is also a good summary of the timeline: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
This is why I don’t use Linux. Insecure as fuck.
Tell you you dont know shit about software development without telling me you dont know shit about software development
Windows user?
This. Everyone knows that windows is a perfectly safe and secure environment with no exploits and vulnerabilities whatsoever.
Unironically, this is true. They are features
This is really bad.
