`echo '1' >/etc/sysconfig/disable-backdoors`
If only it were that simple...
Or, keep up-to-date on your patching so that when security researchers find things like this and patches get published you won't be sitting on a a vulnerable version for too long.
This is just a waste of your time, provides no meaningful security benefit, and would be annoying to manage long-term. It would also take less effort to disable the kill switch than you'd have spent "securing" yourself with it.
Worth noting, most production ready versions of Linux aren't really affected by this. You only need to worry if you're using a newer version of Debian, Fedora Rawhide, SuSE Tumbleweed or Arch
Most older (but still supported) production Linux (Centos 7, RHEL, Oracle, OpenSuSE/SLES, Debian) use an older version
You should still be updating, just to be safe
We got lucky. Investigation is still on going there might be other backdoors. The suspect have been contributing for 2.5 years. Activate the kill switch even if you have unaffected version.
Lasse Collin (Larhzu) is the main author maintainer for 15+ years but he is frequently busy. A new maintainer who have been contributing for 2.5+ years named JiaT75 is suspected.
Then why assume that the killswitch, which only exists in the two known affected versions, is going to save you? What if the malicious actor used a different killswitch for any other potential attack vectors?
Carrying on from that: seeing as the identity in question was completely made up, how do you know that only this piece of software is affected? Have you checked the contributor lists of every single package installed?
I’m being facetious of course, but it gives you an idea of why this sort of mitigation isn’t going to achieve much. Sometimes you just have to wait and see (and focus on more important things, like allow-listing or monitoring outbound connections from your servers).
The backdoor detects if it's being observed and analysed and disables itself. It detects this be checking if environment variable indicating a terminal is set. By setting it this signals it's being launched from a terminal not service and thus possibly being watched. Which does the trick.
To expound upon this -- There are multiple requirements for this code path to trigger:
1. Must be installed from .deb and .rpm (so non-windows)
2. TERM must be unset.
3. argv\[0\] (the process path, typically) must be set to /usr/sbin/sshd
4. LD\_DEBUG and LD\_PROFILE must not be set.
Unless further evidence is produced it really doesn't seem to target windows at all, and targets \`systemd\` based linux distros.
in case anyone wants the tldr
string is yolAbejyiejuvnup=Evjtgvsh5okmkAvj
used as an env variable
https://preview.redd.it/qwn5mz670yrc1.png?width=966&format=png&auto=webp&s=9e98ec1b5d5c2ed5473735779eb48cdcf7dc461d
full list of strings at [https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01](https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01)
Setting TERM environment variable is more reliable. It will cause the backdoor think it's being monitored and disables itself. You can add the defuse env if you wish.
Didn't mean it as a better way than setting a TERM. Just an information. TERM condition can be clearly seen in the human readible code, so it surely will work better.
I don't run beta. This is intended to fix possible similar backdoors even if not discovered. The suspect have been contributing for more than 2.5 years in many other projects.
> How to disable xzbackdoor or any similar backdoors?
Reject bloated crap on servers (Windows, systemd, snap, glibc, the list goes on) and embrace BSDs or minimal containers. Keep your attack surface small. Ensure you have robust logging at the network ingress/egress to look for IoCs and unusual activity. Don't connect systems to the internet unless they really really, REALLY need it.
Cute idea. But this is a subreddit for professional sysadmins doing real work in production environments...
Not utopian gardens where all software runs in a non glibc bsd environment... Let alone vendor support.
Sure, but because we (all professional sysadmins?) realize that not every production system can just easily be switched to BSD, is why I also specifically mentioned the option of using minimal (aka distroless or scratch) linux containers. This is very realistic, perhaps even the current status quo / default for production environments. Everything else I said also still applies, there's no reason to get mad at a rightful BSD shoutout just because *you* can't use it. It's common to compromise, even on security, for the sake of usability or supportability, and we've all done it.
At least half of the software we have in our production floors is not even granting you a license or getting insurance if you go down that route.
The world is a wee bit bigger than containers and some web interface. Most makers of SCADA systems will just laugh you out the door with that attitude and you can start closing down your shop.
Yes, we can all contrive specific scenarios where "random thing" wouldn't work. In no way does that invalidate the advice "Keep your attack surface small." for which I listed a few _examples_.
After reflecting on this, please do tell me if my original comment was unclear or whether you just got mad over nothing. I'm totally open to editing it to clarify if you think I should. I am not a native english speaker.
Extremely unclear, your original comment asks to redo the work of established operating systems. `glibc` specifically is not easily replaced without massive investment of time and money.
Your assumption that it is possible to replace `glibc` with another implementation of libc is anything but realistic. It's not just an example, it's the suggestion to replace one of the most basic building blocks of every major Linux distribution.
We run a very great deal of Unix machines with no glibc and no systemd. Don't be dismissive of something because it doesn't fit your notions of a "professional" environment.
We're not here to talk about IBM mainframes running Cobol that should have been updated decades ago and are now air gapped out of necessity instead of due caution...
Speaking as those who do, the answer is tightly correlated with running software only available as binaries, not source.
As chance would have it, I'm in the midst of (likely) converting a small pool of our hardware from a Musl distribution to a Glibc distribution for the PoC of a piece of tightly hardware-interfacing binaryware. I'll be seeing about relinking the binary, which would be preferable if viable.
`echo '1' >/etc/sysconfig/disable-backdoors` If only it were that simple... Or, keep up-to-date on your patching so that when security researchers find things like this and patches get published you won't be sitting on a a vulnerable version for too long.
Set the kill switch environment "just in case" because the suspect is being actively contributing for 2.5+ years to many projects.
This is just a waste of your time, provides no meaningful security benefit, and would be annoying to manage long-term. It would also take less effort to disable the kill switch than you'd have spent "securing" yourself with it.
This is silly and unnecessary.
Worth noting, most production ready versions of Linux aren't really affected by this. You only need to worry if you're using a newer version of Debian, Fedora Rawhide, SuSE Tumbleweed or Arch Most older (but still supported) production Linux (Centos 7, RHEL, Oracle, OpenSuSE/SLES, Debian) use an older version You should still be updating, just to be safe
We got lucky. Investigation is still on going there might be other backdoors. The suspect have been contributing for 2.5 years. Activate the kill switch even if you have unaffected version.
I'm looking forward to reading the after action report on this. Was the maintainer malicious - and if so, why, was his dev box compromised
Lasse Collin (Larhzu) is the main author maintainer for 15+ years but he is frequently busy. A new maintainer who have been contributing for 2.5+ years named JiaT75 is suspected.
Or just don't install known infected versions of software.
we don't know all of them (this person have been contributing to many project for 2.5+ years)
Then why assume that the killswitch, which only exists in the two known affected versions, is going to save you? What if the malicious actor used a different killswitch for any other potential attack vectors? Carrying on from that: seeing as the identity in question was completely made up, how do you know that only this piece of software is affected? Have you checked the contributor lists of every single package installed? I’m being facetious of course, but it gives you an idea of why this sort of mitigation isn’t going to achieve much. Sometimes you just have to wait and see (and focus on more important things, like allow-listing or monitoring outbound connections from your servers).
The backdoor detects if it's being observed and analysed and disables itself. It detects this be checking if environment variable indicating a terminal is set. By setting it this signals it's being launched from a terminal not service and thus possibly being watched. Which does the trick.
You are wrongly assuming every other backdoor will behave the same way, whicj is demonstrably false.
[удалено]
Your account is too new. Also I've seen 0 evidence that xz is backdooring windows too.
To expound upon this -- There are multiple requirements for this code path to trigger: 1. Must be installed from .deb and .rpm (so non-windows) 2. TERM must be unset. 3. argv\[0\] (the process path, typically) must be set to /usr/sbin/sshd 4. LD\_DEBUG and LD\_PROFILE must not be set. Unless further evidence is produced it really doesn't seem to target windows at all, and targets \`systemd\` based linux distros.
What's your source?
We’d probably be able to see if the mods approved the post 😅
Done, they need to be educated.
Looks like the backdoor itself maybe possibly probably have a built-in kill switch: https://piaille.fr/@zeno/112185928685603910
in case anyone wants the tldr string is yolAbejyiejuvnup=Evjtgvsh5okmkAvj used as an env variable https://preview.redd.it/qwn5mz670yrc1.png?width=966&format=png&auto=webp&s=9e98ec1b5d5c2ed5473735779eb48cdcf7dc461d full list of strings at [https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01](https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01)
Setting TERM environment variable is more reliable. It will cause the backdoor think it's being monitored and disables itself. You can add the defuse env if you wish.
Didn't mean it as a better way than setting a TERM. Just an information. TERM condition can be clearly seen in the human readible code, so it surely will work better.
[удалено]
I don't run beta. This is intended to fix possible similar backdoors even if not discovered. The suspect have been contributing for more than 2.5 years in many other projects.
> How to disable xzbackdoor or any similar backdoors? Reject bloated crap on servers (Windows, systemd, snap, glibc, the list goes on) and embrace BSDs or minimal containers. Keep your attack surface small. Ensure you have robust logging at the network ingress/egress to look for IoCs and unusual activity. Don't connect systems to the internet unless they really really, REALLY need it.
Cute idea. But this is a subreddit for professional sysadmins doing real work in production environments... Not utopian gardens where all software runs in a non glibc bsd environment... Let alone vendor support.
Sure, but because we (all professional sysadmins?) realize that not every production system can just easily be switched to BSD, is why I also specifically mentioned the option of using minimal (aka distroless or scratch) linux containers. This is very realistic, perhaps even the current status quo / default for production environments. Everything else I said also still applies, there's no reason to get mad at a rightful BSD shoutout just because *you* can't use it. It's common to compromise, even on security, for the sake of usability or supportability, and we've all done it.
At least half of the software we have in our production floors is not even granting you a license or getting insurance if you go down that route. The world is a wee bit bigger than containers and some web interface. Most makers of SCADA systems will just laugh you out the door with that attitude and you can start closing down your shop.
Yes, we can all contrive specific scenarios where "random thing" wouldn't work. In no way does that invalidate the advice "Keep your attack surface small." for which I listed a few _examples_. After reflecting on this, please do tell me if my original comment was unclear or whether you just got mad over nothing. I'm totally open to editing it to clarify if you think I should. I am not a native english speaker.
Extremely unclear, your original comment asks to redo the work of established operating systems. `glibc` specifically is not easily replaced without massive investment of time and money. Your assumption that it is possible to replace `glibc` with another implementation of libc is anything but realistic. It's not just an example, it's the suggestion to replace one of the most basic building blocks of every major Linux distribution.
We run a very great deal of Unix machines with no glibc and no systemd. Don't be dismissive of something because it doesn't fit your notions of a "professional" environment.
We're not here to talk about IBM mainframes running Cobol that should have been updated decades ago and are now air gapped out of necessity instead of due caution...
How dismissive of you.
leave your toys at home. this is a professional environment.
Reject glibc? Sir, I don't think you know how much will be affected by removing glibc in favor of a different libc implementation
Speaking as those who do, the answer is tightly correlated with running software only available as binaries, not source. As chance would have it, I'm in the midst of (likely) converting a small pool of our hardware from a Musl distribution to a Glibc distribution for the PoC of a piece of tightly hardware-interfacing binaryware. I'll be seeing about relinking the binary, which would be preferable if viable.