openSUSE addresses supply chain attack against xz compression library (news.opensuse.org)
from Archaeopteryx@discuss.tchncs.de to linux@lemmy.ml on 29 Mar 2024 20:50
https://discuss.tchncs.de/post/13377347

openSUSE maintainers received notification of a supply chain attack against the “xz” compression tool and “liblzma5” library.

Background

Security Researcher Andres Freund reported to Debian that the xz / liblzma library had been backdoored.

This backdoor was introduced in the upstream github xz project with release 5.6.0 in February 2024.

Our rolling release distribution openSUSE Tumbleweed and openSUSE MicroOS included this version between March 7th and March 28th.

SUSE Linux Enterprise and Leap are built in isolation from openSUSE. Code, functionality and characteristics of Tumbleweed are not automatically introduced in SUSE Linux Enterprise and/or Leap. It has been established that the malicious file introduced into Tumbleweed is not present in SUSE Linux Enterprise and/or Leap.

Impact

Current research indicates that the backdoor is active in the SSH Daemon, allowing malicious actors to access systems where SSH is exposed to the internet.

As of March 29th reverse engineering of the backdoor is still ongoing.

Mitigations

openSUSE Maintainers have rolled back the version of xz on Tumbleweed on March 28th and have released a new Tumbleweed snapshot (20240328 or later) that was built from a safe backup.

The reversed version is versioned 5.6.1.revertto5.4 and can be queried with rpm -q liblzma5.

User recommendation

For our openSUSE Tumbleweed users where SSH is exposed to the internet we recommend installing fresh, as it’s unknown if the backdoor has been exploited. Due to the sophisticated nature of the backdoor an on-system detection of a breach is likely not possible. Also rotation of any credentials that could have been fetched from the system is highly recommended. Otherwise, simply update to openSUSE Tumbleweed 20240328 or later and reboot the system.

More Information about openSUSE:

#linux

threaded - newest

CommunityLinkFixer@lemmings.world on 29 Mar 2024 20:52 next collapse

Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn’t work well for people on different instances. Try fixing it like this: !open@discuss.tchncs.de

Pantherina@feddit.de on 29 Mar 2024 21:43 next collapse

Damn this is really bad. Good that they fixed it.

Link@rentadrunk.org on 29 Mar 2024 23:12 collapse

I wouldn’t be surprised if older versions have a backdoor too as they were a maintainer for 2 year so who knows what they added.

Pantherina@feddit.de on 29 Mar 2024 23:18 next collapse

Damn… damn!!

SheeEttin@programming.dev on 30 Mar 2024 03:19 collapse

Someone is going back over their contributions, right?

Right?

thayer@lemmy.ca on 30 Mar 2024 07:50 collapse

Right, here’s an enlightening synopsis by Evan Boehs:

boehs.org/…/everything-i-know-about-the-xz-backdo…

floofloof@lemmy.ca on 29 Mar 2024 22:13 next collapse

It’s good that it didn’t get into Leap or Enterprise. Servers for businesses shouldn’t generally be using Tumbleweed.

It sounds like to be really vulnerable a machine has to expose SSH to the internet. So if that’s correct then most typical home computers should be safe. Based on that assumption I’m not rushing to wipe and reinstall.

redcalcium@lemmy.institute on 29 Mar 2024 22:46 next collapse

What scary is the maintainer that insert the backdoor has been main maintainer for xz for the last two years. Who know if they have other backdoors inserted in the last 2 years? Investigation is still ongoing so I expect more juicy revelations in the next few days.

Lime66@lemmy.world on 30 Mar 2024 10:21 collapse

doesn’t pushing to github (and probably a selfhosted equivalent) require ssh to do without entering your password every single time?

raptir@lemdro.id on 29 Mar 2024 22:48 next collapse

I assume SSH is not exposed to the internet by default on openSUSE? I have not used SSH on my install so should I be safe if I just update?

eduardm@lemmy.world on 29 Mar 2024 22:55 next collapse

If you didn’t explicitly open the SSH port during the install, you are okay.

[deleted] on 30 Mar 2024 00:26 next collapse

.

Ephera@lemmy.ml on 30 Mar 2024 06:28 collapse

On desktop systems, the SSH server is disabled by default. It should say “disabled” in systemctl status sshd, then you’re good.

On server systems, the SSH server is enabled, but you would usually know that it accepts incoming connections from the internet.
So, a home-server would need to be exposed in your modem/router. And if you’re hosting on a VPS, well, then it’s obviously going to be reachable.

federalreverse@feddit.de on 29 Mar 2024 23:11 next collapse

So this is what happens when package maintainers fail to find the problematic bits during package updates. I’ll be honest, after seeing how Linux package management is done (automation and semi-automation galore) and by whom (people who often don’t know the programming language of the source and who don’t have much time either), I am more surprised that it took this long.

eveninghere@beehaw.org on 29 Mar 2024 23:31 next collapse

Yes, ~it took a security researcher to find this out~. Package manager maintainers failed, and they were whom the average Linux advocate supposed will catch the back door, whenever they boasted about the safe-ness of Linux.

[deleted] on 29 Mar 2024 23:47 collapse

.

eveninghere@beehaw.org on 29 Mar 2024 23:55 collapse

OP wrote security researcher reported to Debian, so I’m mildly confused to read your reply.

[deleted] on 30 Mar 2024 00:00 collapse

.

eveninghere@beehaw.org on 30 Mar 2024 00:43 collapse

Right. His Mastodon bio also says he’s a postgres dev at MS. Something went wrong by the time this post was done.

baru@lemmy.world on 30 Mar 2024 01:35 collapse

In this case the upstream maintainer heavily obfuscated the code to be able to compromise ssh. Package maintainers aren’t responsible for vetting for that.

Killing_Spark@feddit.de on 30 Mar 2024 06:41 collapse

The original email talks about a line that is in the release tar balls but not the repository itself that actually arms the exploit. This seems like something a maintainer should be able to verify.

Not saying that they should have immediately seen that that is an exploit, the exploit is obfuscated very well. But this should be a big red flag right?

SMillerNL@lemmy.world on 30 Mar 2024 09:28 collapse

As a Homebrew maintainer, what is there to red flag about a project providing tarballs of their source?

We would have to red flag pretty much every project that uses autoconf (since those usually provide a tarball where the user doesn’t have to run autoreconf)

Killing_Spark@feddit.de on 30 Mar 2024 11:45 collapse

I have to admit I have no practical experience as a package maintainer, but this case sounds like there is a diff between files checked into the repo and the ones provided by the tarball.

If the tarball contains new files that contain executable code that’s still weird tbh, but I guess you have to trust the upstream maintainers to some degree. But a diff in a checked in file seems different to me.

ReversalHatchery@beehaw.org on 30 Mar 2024 00:24 next collapse

It’s quite interesting to see that the developer who has embedded the backdoor “simplified” the SECURITY.md file just 4 days ago, by deleting information about how to report a security vulnerability.
The reason it’s really interesting is that if I understand it right, the backdoor was just discovered less than a day ago.

github.com/…/af071ef7702debef4f1d324616a0137a5001…

nailoC5@lemy.lol on 30 Mar 2024 00:47 collapse

I think they only started pushing for updated version on Fedora and Debian a few days ago.

ReversalHatchery@beehaw.org on 30 Mar 2024 00:53 collapse

It would also be interesting to know if any OS was in feature freeze recently that is not supposed to get updates anymore. I was thinking about Android, OpenWRT or any of those where people update update their devices more rarely

user134450@feddit.de on 30 Mar 2024 12:45 collapse

OpenWRT does not use liblzma or systemd so i think that one is pretty safe. I would also be surprised if Android included OpenSSH server binaries in that way.