BTW @Android_Gynous … forgot to ask - have you executed the detect script?
And if yes, what was the result. If no, why not run it and respond back 
1 Like
have you executed the detect script?
And if yes, what was the result. If no, why not run it and respond back
Not yet. But I plan to when I get home from work tonight!
Will report back. 
I just applied the whole(2506 packages) update using the TTY method, but I just read somewhere else that not even a fresh install can be trusted if the TW ISO was downloaded on the (possibly) already compromised system.
Two questions: can it be safer if I download the ISO on a friend’s MAC and then create the USB media on it?
Is a MicroOS system a safer choice or can it be affected too?
I current run yara with checkfile from CVE-2024-3094-info/CVE-2024-3094.yar at main · byinarie/CVE-2024-3094-info · GitHub and become aware that all snapshots over the last three weeks contain the vulnerable liblzma. So be careful using snapshots!
The malicious version of the xz package was acting as backdoor, in short if you have the malicious version running on your system while having an SSH server running and this server is exposed to the internet then you should consider your installation compromised meaning it is better to reinstall your system with a fresh install since you cannot know if someone did use the backdoor to gain full access of your computer and if it was the case what was done on your computer…
If your system was compromised yes it is safer to create the bootable media from a clean computer, but that’s the theory in practice it is unlikely that a process is running on your system making sure to corrupt any ISO it can find …
I think if an attacker did gain root access on your computer it is safer to assume that system snapshots are compromised too.
That is not the point. If an attacker had access, there is no alternative than install fresh. But assuming the condition for activating the backdoor was not fulfilled, you could open the backdoor again unintentionally.
1 Like
As a follow-up, plus new thoughts about this.
Before I did the update to “5.6.1.revertto5.4” for xz and liblzma, I ran the check script and it reported probably vulnerable.
After I did the update, I run the script and it reports probably not vulnerable.
If you DID NOT run the script before applying the changes, you will only see probably not vulnerable.
So the script basically is doing a sort of checksum value on the binaries. And if someone has applied the patch/fix, my interpretation is, “you’re already potentially vulnerable” because the binaries were already in a compromised state for quite some time (before the patch update).
So, before applying the patch update, the backdoor might already be on the system. Just because you applied the patch update TODAY, doesn’t mean you’re fine, because the vulnerable version of xz has been in place for a while.
Also, if you have SSD installed and active as an option … it doesn’t matter if you’ve NOT actually used SSH in quite a while … because the SSH daemon (sshd) is launched during start-up. (my understanding).
So, before applying the patch update, the backdoor might already be on the system. Just because you applied the patch update TODAY, doesn’t mean you’re fine, because the vulnerable version of xz has been in place for a while.
That is correct. In my case I assume not to be affected cause
sudo systemctl status sshd.service
sshd.service - OpenSSH Daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; preset: disabled)
Active: inactive (dead)`
which sshd
which: no sshd in (/home/xxx/.local/bin:/home/xxx/bin:/usr/local/bin:/usr/bin:/bin)
If there are no other ways where xz is loaded I get away with a black eye.
On TW, sshd is not found using which, because sshd on TW is in /usr/sbin/
Run this:
# whereis sshd
1 Like
Ok found, but still not loaded.
One more question: I read in an article that the backdoor is not executed if TERM is set. In my system echo $TERM prints xterm-256color. Could this be the all-clear signal? Is this variable set by tumbleweed with that default value?
Thank you for the thorough info.
1 Like
As with all things related to security, it’s a risk assessment and balance equation, and one each user has to make for themselves.
Ask yourself these questions:
- What is the risk that I was an interesting enough target that a backdoor, installed through the supply chain (rather than targeted directly at me), would result in the adversary targeting my specific system specifically?
- What is the sensitivity of the data that I hold on my system that would be of interest to someone who, in the event that my system did become compromised through this attack would be waiting for my system to be compromised so they could leverage the backdoor to gain access to that information?
- How long was the backdoor potentially installed on my system - ie, what was the ‘window of opportunity’ for the attacker?
- What other measures are in place in your network that would hinder an attacker from leveraging this exposure? (ie, do you have a router between your system and the Internet; are you using NAT on that router; are you using port forwarding for SSH at your router to connect directly to an affected system from the Internet)
If you applied the massive update, it’s unlikely that a fresh ISO downloaded to your system would be specifically targeted by code on your system and then be modified in such a way as to compromise your system after a full reinstall from scratch. That would require foreknowledge of what was going to be on the ISO and how to modify it, and that would be an extremely unlikely thing for a relatively small code change to be written for (ie, it would have to be very specifically an attack against a specific openSUSE ISO, and would have to know what was going to be included on the ISO as well as be assured that the user would pick the options necessary for the ‘infected’ package to be included).
Consider as well that the developer who did this compromised a library in the supply chain to the build of that ISO. Is it likely that they would have then also written that compromise to compromise the media of a future download, when they’ve already demonstrated that they were able to do this without getting to the ISO on anyone’s system in the first place? To me, that seems unlikely. Possible? Sure. But not highly probable.
The probability of this being the case is probably less than that of winning the lottery. Possible? Sure. But extremely unlikely.
MicroOS is based on Tumbleweed, and was affected by this specific supply chain exploit, if you updated during the time the compromised library was included in the repos.
But, again, when it comes to evaluating a security stance for a system, it’s all about probabilities and liklihoods. There are things that you, as a system administrator/operator can do that expose your system to higher risks. There are things you can do to make your system more resistent to attacks.
But anyone who says that there are ways to guarantee that your system isn’t compromised doesn’t understand how security works. It’s usually a balance between convenience and hardening of the system.
There have been (to my knowledge) zero reports of this being exploited in the wild. The window that the compromised libraries were on affected systems is less than a month (and for those who don’t update their TW installations frequently, it would be less than that). Then there’s the combination of factors that would result in the compromise actually being usable - like SSH being open to the Internet at large. Like the various checks in the code for specific circumstances.
While the investigation is ongoing, I’ve not seen anything that indicates that this compromise included a “phone home” component, so compromising a system using this exploit would be a very difficult thing to do.
If I had to guess at the developer’s motivation, it wasn’t to actually compromise systems, but to create panic and uncertainty in the code supply chain for Linux - that it was a “proof of concept”. Maybe someday we’ll learn what they’re actual motivation was - it was clearly an deliberate change and not an honest mistake.
It’s important to consider all of these factors and then make a decision, rather than making a decision in a panic and imagining the worst.
2 Likes
Are you sure about that? I ask because the check (script) is against sshd, not xz and liblzma (, correct?). So if the checksum for sshd isn’t correct, then it seems installing ssh-server afresh (or updating it) should be done - or remove it.
Thank you for the advices and all your time
1 Like
TERM won’t be set for a process if the process is not launched from an interactive terminal. If you have sshd being started from any init system, TERM will not be set in that processes environment.
Not running the backdoor if TERM is set is a very low effort way to try and prevent analysis or discovery of the process.
That your interactive session has TERM set is both expected and also not in any way a protection.
1 Like
Thank you for the explanation. The background of my question is that I am sure sshd is not started by systemd on my system since installation. So I am looking for an attribute which could prevent execution of the backdoor (and was set in the past) if there would be other methods running xz.
You are going to have to wait for a complete analysis.
1 Like
1 Like
I’ve been reading all the posts at seclists.org, started by the “savior” 
, where I discovered this graphic. Just finished reading the last / most current reply for now.
Anyway, I found this graphic that was created so folks can get a nice visual timeline of the xz malware. The image is first, then I offer the URL to the specific Reply where it is found.
The backdoor went effective Mar 9.
==== Quote, plus URL ====
Much of the scripted part of the backdoor is now also illustrated by
Thomas Roccia @fr0gger_ in:
https://twitter.com/fr0gger_/status/1774342248437813525
I’m attaching a scaled down and color-reduced (but legible) version of
the image (“convert -strip -quality 100 -resize 50% -colors 12”).
==== end quote ====
1 Like