So if you DON’T use sshd and not running a server, all is okay?
I just checked on my TW and SSH is allowed in the firewall. And i know for a fact i have not tinkered with it myself.
Why is SSH allowed by default?
2 Likes
@Teroh On the final installer page, did you check the options enabled/disable sshd/firewall before proceeding with the install?
Are you behind a router/firewall out to the internet? Is that router/firewall port forwarding to your machine and ssh port?
Do you use ssh, if not disable the service (from memory the port is open but the sshd service is disabled)…
1 Like
I dont remember the last page of the install.
I am behind a router and already checked : The sshd service is disabled and the TW firewall is running.
Was just curious why ssh would be allowed or if its required for any core functionality. Otherwise i might wanna move ssh to disallowed.
@Teroh If you ever install again, make a point of checking it all out 
I use ssh/sftp/scp/sshfs exclusively around here for my systems, none are internet facing, internet facing router is all locked down though… On the road laptop has no services running by default, so not an issue there.
1 Like
ssh isn’t required for any core functionality, but IIRC most folks use it if they have more than one system in order to access it remotely. But as noted, during install you can decide to disable it in your installation if you choose.
1 Like
For now, sshd is the one we know for certain it targets. It could target other services/components that we don’t know of yet. That is to say, the spotlight on sshd is to some extent overshadowing the true culprit (xz/lzma) that is quite literally everywhere including systemd (PID 1) and selinux (thanks @elvigia !) among others.
Think of it like the sewer monster from IT who’s currently sitting underneath your home with access to all your plumbing, we know it messes with the water so the immediate fix is to turn off the tap but it could also mess with the gas line and blow up your house next. We just don’t know yet, but we do know that it has the access to do that 
1 Like
Does running ‘xz’ command as root make the situation worse? Just two days ago I happened to run ‘xz’ as root to create a raspberry pi drive…
@Teroh Ssh is disabled by default. Firewall is on by default. So you did change that.
1 Like
Nope, it is not that simple. The installer decides based on different choices whilst installation, if it enables ssh. It also depends on your overall setup. As example, if another OS is detected in your system, ssh will be enabled by default in the installation process.
2 Likes
as far as I know only the server installation does that. However (different discussion too) TW as a server is generally not a good idea (and the xz issue is one example of it). When it comes to dual/multiboot, I never have seen that but possibly missed that, yes.
I always check the last displayed information about what the install is going to do.
would the lamp pattern do this?
i have tended to select this due to my interest in nextcloud, and wanting those bits enabled for me (because i don’t want to have to figure out how to do it myself). that’s what the patterns are there for after all.
There are countless variables that enable ssh whilst installation automatically. Even on plain desktop TW systems. I do setup some VMs weekly for testing purposes and 50% of them have ssh enabled by default (i do disable it at the summary page…).
1 Like
Certainly, the trigger is “server”…
There’s a shell script available for download [1] (detect.sh) whereby a response of either:
probably vulnerable
...or...
probably not vulnerable
I spent a quite a bit of time reading the responses out at “lwn.net”. Since TW is a rolling, “gets updates earlier than other distros”, this vulnerability was introduced a while back (in terms of zypper dups).
I ran the script on my main install of TW on my laptop - results:
probably vulnerable
I ran it on two virtual machines on this laptop, which are
(1) an install of TW with KDE Plasma 6 from an ISO from 03/28, and
(2) an install of TW with IceWM from an ISO from 03/25, which I have not updated (zypper dup) since orig install.
Results are … for the VM TW KDE install:
probably not vulnerable
And for the VM TW IceWM install:
probably vulnerable
I’ve since deleted both virtual machines. BTW, the “detect” script will not successfully run without modifications for TW. Why? Because the script runs:
which sshd
(which: no sshd in (/home/myhome/bin:/usr/local/bin:/usr/bin:/bin) )
… it won’t be found because in TW, sshd is in /usr/sbin/
So, I modified the script to hard-code the path for sshd:
# find path to liblzma used by sshd
path="$(ldd '/usr/sbin/sshd' | grep liblzma | grep -o '/[^ ]*')"
So, my next steps for my laptop is to install from scratch. I’m still debating on whether to install Slowroll or Leap (15.6-beta?) … to avoid any possible future vulnerabilities because of being “on a bleeding edge” rolling distro 
.
[1] Script written by Vegard Nossum, found here:
https://www.openwall.com/lists/oss-security/2024/03/29/4
1 Like
So, my next steps for my laptop is to install from scratch. I’m still debating on whether to install Slowroll or Leap (15.6-beta?) … to avoid any possible future vulnerabilities because of being “on a bleeding edge” rolling distro
Honestly, I do think that is a bit overboard. As of the moment I’m writing this the evidence shows that the payload’s only final result was the deployment of the backdoor itself, and nothing more(that may change after it is fully reverse engineered). All signs atm are pointing to this being a state sponsored operation for use of deploying future attacks.
A backdoor on it’s own is just that, a backdoor. Switching to Slowroll, Leap, a non-rolling distro, or another distro entirely are essentially just giving yourself over to paranoia. As it has already been mentioned in this thread, this particular contributor had been making contributions to this project and many others since 2022. This means there may have been many more backdoors deployed over a much larger time frame, that no short term rollback-mitigation would be effective. This is also not to mention, all the potential other backdoors that may have been snuck into other libraries that we are not even aware of yet. If this proven accurate, it would mean that even older, stable distros could be effected. The only reason we know about this one is because some rando decided to investigate why their latency was higher than normal. We got lucky.
My conclusion is this. If you’re running a server, yeah…maybe a good idea to do a fresh install. If you are on desktop, patch…disable ssh…wait and see.
Thanks for the feedback and observation!!
Yes, xz has been updated to “5.6.1.revertto5.4” … it’s a desktop only, and SSH is disabled (hasn’t been used in months), and removed all SSH entries in the firewall.
Pretty much my stance on this as well as of right now.
We all got absurdly lucky that someone actually benchmarked their ssh connections and had the knowledge to debug it and had the knowledge to trace it back and knew the right channels to report and … and … and …
And i don’t think the attack vector was : “Screw with random rolling distro user”. The attack was clearly aimed at Redhat and SUSE, but at their upcoming mayor business releases.
They wanted the backdoor in the new stable releases, so they could wait until docker updates their default ISO’s and then attack all the nodes that run on that new docker image.
But then again … this is all personal tinfoil and we have to wait for this to unfold truely.
1 Like
That probability statement would concern me too.
And thanks for the info on the shell script … I will run it on all my machines.
I glanced thru the thread - it seems Aggie only mentioned running it.
Anyone else in here run the check script on their machine??
Incoming rebuild…New Tumbleweed snapshot 20240329 released! - openSUSE Factory - openSUSE Mailing Lists
@myswtest I did yesterday, I changed the “echo probably not vulnerable” to “echo your system is awesome” to allay any fears to my admin self… 
3 Likes