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.
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.
Fortunate we are for now, but it might have been some other utility. I think in future this sort of attack will become more commonplace.
The news swirling around this is making my blood boil. For months a year or two back, github had been blogging about their upcoming changes, sending me emails, on the importance of the supply chain, and how their soon to be mandated authentication mechanisms were securing the supply chain. Someone can steal your password from site A and use it on github. Passwords are sooo insecure -- we have to move on from passwords! Somebody can break into your account and start pushing changes to repositories you share commit access with if you use passwords!
Someone just said this was a supply chain attack, and they are right, so to speak. So the blood started to boil on those words, considering the news speak github has been engaged in for some time. How did the supply chain attack occur? Someone created a github account. That's it. It's that easy. And then it's social engineering from there. So much for blogging how secure things are if we just accept github's way. I guess github is concerned about all those one line changes I have spent the time to put through formal pull requests.
I pissed someone off just a few days ago, adding binaries files and a mashup of changes in one commit, and then I rejected it and telling the guy to create proper clear set of patches with descriptions that can be reviewed. The response I basically got, "what do you mean? my code is clear!". I think there is github, and there is git. I no longer see github as being a git repository system, but just a proprietary website that just happens it can speak some git behind the scenes if you jump through the hoops. Evidence of this is how so many projects are being maintained. They are not maintained on github in the way I would expect with most any revision control system. In fact, I would consider github is a place to dump and share files at this point. Github is not all at fault here. But I'm really kind of poking at irony in github's communication the past couple years.
Last edited by the3dfxdude; 03-30-2024 at 10:20 AM.
The scope of this attack is not yet fully analysed. Therefore, I tend to treat any source code coming from the co-maintainer of xz (Jia Tan) as an absolute threat. For instance, Lasse Collin (the original maintainer of xz), found another sabotage in the code.
I performed the following steps on my Slackware64-current to go back to xz-5.2.5 (same as Slackware64-15.0):
Code:
- removed xz (5.6.1) --> be careful, from this point onward, your system has no lzlma support
- deleted /lib64/libzlma.so.5.6.1 by hand (belongs to aaa_libraries package at this point)
- using lftp, mirrored the a/xz from slackware64-15.0 "sources" dir.
- using lftp, mirrored the a/aaa_libraries from slackware64-current "sources" dir.
- extracted the "xz-5.2.5.tar.xz" inside "a/xz/" with an old version of "xz" (from another machine).
- adapted the xz.SlackBuild
- Bump the BUILD number
- Use the tar file (instead of tar.xz)
- Produce a "tgz" (instead of "txz")
- built and installed xz-5.2.5
- rebuilt the "a/aaa_libraries" and installed it.
- regenerated the initramfs image, because it contains a copy of "libzlma"
I chose not to blacklist "xz" for now, because I want to closely follow whatever changes are done in the -current.
One can follow Lasse's page for extra facts and links.
Last edited by slackbit; 03-30-2024 at 10:42 AM.
Reason: Referenced Lasse's page
The scope of this attack is not yet fully analysed. Therefore, I tend to treat any source code coming from the co-maintainer of xz (Jia Tan) as an absolute threat. For instance, Lasse Collin (the original maintainer of xz), found another sabotage in the code.
I performed the following steps on my Slackware64-current to go back to xz-5.2.5 (same as Slackware64-15.0):
Code:
- removed xz (5.6.1) --> be careful, from this point onward, your system has no lzlma support
- deleted /lib64/libzlma.so.5.6.1 by hand (belongs to aaa_libraries package at this point)
- using lftp, mirrored the a/xz from slackware64-15.0 "sources" dir.
- using lftp, mirrored the a/aaa_libraries from slackware64-current "sources" dir.
- extracted the "xz-5.2.5.tar.xz" inside "a/xz/" with an old version of "xz" (from another machine).
- adapted the xz.SlackBuild
- Bump the BUILD number
- Use the tar file (instead of tar.xz)
- Produce a "tgz" (instead of "txz")
- built and installed xz-5.2.5
- rebuilt the "a/aaa_libraries" and installed it.
- regenerated the initramfs image, because it contains a copy of "libzlma"
I chose not to blacklist "xz" for now, because I want to closely follow whatever changes are done in the -current.
One can follow Lasse's page for extra facts and links.
Andrew (and anyone else), please do not take this code right now.
Until the backdooring of upstream xz[1] is fully understood, we should not
accept any code from Jia Tan, Lasse Collin, or any other folks associated
with tukaani.org. It appears the domain, or at least credentials
associated with Jia Tan, have been used to create an obfuscated ssh
server backdoor via the xz upstream releases since at least 5.6.0.
Without extensive analysis, we should not take any associated code.
It may be worth doing some retrospective analysis of past contributions
as well...
Lasse, are you able to comment about what is going on here?
Code:
Thank you. None of these patches are urgent. I'm on a holiday and only
happened to look at my emails and it seems to be a major mess.
My proper investigation efforts likely start in the first days of
April. That is, I currently know only a few facts which alone are bad
enough.
Info will be updated here: https://tukaani.org/xz-backdoor/
--
Lasse Collin
shows the binary built with cmake and the fixed CMakeCache.txt does contain it, but the binary built with the sabotaged landlock sandbox check does not. And, the binary now in -current built with configure+make does not.
I was wrong. I didn't strip the binaries I built with cmake. When I removed strip from Pat's Slackbuild, it also showed the landlock strings in /bin/xz.
So: thanks to our BDFL, /bin/xz in Slackware already used the landlock sandbox because of not using cmake.
configure found '#define HAVE_LINUX_LANDLOCK 1' but cmake didn't find it with the sabotaged check.
So if this video is to be confirmed as true, it sounds like this was done over a long period of time; adding bits of changes here and there that ended up being the exploit...? - If so, kinda means now more 'smaller' or insignificant commits to code might have to be looked at closely, and considered if adding the code adds any real benefit (if thats somehow even feasible to do - I realize code auditing takes time); but I guess this is where things are going now - supply chain attacks and very slow infiltration of bits of code that by itself doesn't do anything until everything is in place...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
what commit it aint nothing but a blank line 
