SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
There are reports that xz versions 5.6.0 and 5.6.1 contain a backdoor that was inserted upstream reported here. This allows a ssh exploit.
I think this affects slackware current but not 15.0 which is still on xz version 5.2.5.
actually, as Petri explained in another topic, our sshd doesn't link to liblzma because it doesn't use systemd's notifications (we don't have systemd, thanks to our BDFL!), so even if the malicious code is present in the xz source tarball in current sshd is not actually vulnerable.
you can try the detect script in the openwall message, it won't find any liblzma as a dependency to sshd so it will have an empty output.
actually, as Petri explained in another topic, our sshd doesn't link to liblzma because it doesn't use systemd's notifications (we don't have systemd, thanks to our BDFL!), so even if the malicious code is present in the xz source tarball in current sshd is not actually vulnerable.
you can try the detect script in the openwall message, it won't find any liblzma as a dependency to sshd so it will have an empty output.
The detect script modified to just check our liblzma does not find the fingerprint for the backdoor, so our liblzma is not vulnerable, nor do we patch sshd to link to libsystemd (which would then bring in liblzma).
I might rebuild from a git pull to shed the poisoned m4 files from our sources. Or maybe not... I'm really not sure the git repo can be trusted at this time.
Yet another reason to be thankful for Pat not having adopted systemd!
Still, this may be much larger than this specific bug; lots of detective activity going on right now related to other code contributions by that bad actor.
Yet another reason to be thankful for Pat not having adopted systemd!
Still, this may be much larger than this specific bug; lots of detective activity going on right now related to other code contributions by that bad actor.
See this discussion on Hacker News. Apparently this actor had made contributions to other packages; their Github account has other code that may also be compromised. Essentially anything written by this person is suspect and needs to be reviewed with a fine comb.
From what I can gather, it looks to be targeting Debian and Ubuntu systems mainly. Most distributions, even with systemd, use a vanilla sshd build, IE Arch. This looks to be a targeted attack against those systems that use the Debian/Ubuntu patch. Even the Arch build doesn't use anything but a vanilla implementation.
These malicious actors are getting more and more bold and brazen doing long term infiltration into projects. I really hope other projects aren't being hit the same way.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
