https://www.linuxquestions.org/quest...ol-4175735491/

The Fedora guys are jumping up and down about a backdoor in xz-5.6.0 & 5.6.1 which involves systemd. Current of 2024-03-22 has xz-5.6.1, but not, of course systemd. No sir!

What's the recommended course of action here, or can I go back to sleep?

Upgrade your system and go sleep ;=)

2 members found this post helpful.

Haha. Thanks.

Yep same here im going back to rebuilding my python3 modules....

Slackware is not affected by the known liblzma backdoor from upstream source packages and does not build with cmake.

However, there are still more commits made by the bad actor which has to be investigated.

regards Henrik

3 members found this post helpful.

Thanks. I don't get the import of "[Slackware] does not build with cmake."
Could you elaborate?

And if this is a sign of anything, maybe everyone should restrict their open source stuff on github. A bad actor has come along and make commits with evil intent, and opened a backdoor. If it has happened once, it can happen again... and again...etc.

EDIT: Personally, I'm more likely to be affected by python3.9 --> python3.11. We've been on 3.9 for a good while.

1 members found this post helpful.

I understood the problem is with autoconf, not cmake.

Also that the problem is far from beeing fully investigated and github has closed the tukaani xz project.

Some other distribution revert to 5.4 and don't try to use 5.6 even with no systemd and without the binary problematic files. But even 5.4 maybe suspicious. Server Ubuntu 22 distribution is with 5.2 version of xz.

The new problem is that the saboteur prohibited the use of Landlock sandbox with cmake builds. The sandbox should "help mitigate the security impact of bugs or unexpected/malicious behaviors in user space applications".

2 members found this post helpful.

So then this was an oversight - and those in charge of the repo should have perhaps questioned 'why is said feature prohibited' ? Seems to me this is the new way of attack going forward , bits of code that either do not offer any real improvement or stability, and potentially have smaller malicious intent or say the very least questionable intent, yet on its own it does nothing, until another piece of code later on builds on that. So yea, going forward now even every bit of 'changes' needs to be scrutinized even if it is either benign or has no immediate impact - but should still be looked at and questioned: "why was it written this way?" "Why the need of prohibiting this one protective feature to run or compile?"

Slightly off-topic. This backdoor is it logged to check with command If yes with which user?

I don't think any researchers have been able to observe an unauthorized login, so we don't currently know if it leaves any residue in the logs. I doubt that it would, though.

But for this miscalculation this compromise might never have been noticed (and someone buy Andres Fruend a drink?)?:

"Subsequently the injected code (more about that below) caused valgrind errors
and crashes in some configurations, due the stack layout differing from what
the backdoor was expecting. These issues were attempted to be worked around
in 5.6.1:"

https://www.openwall.com/lists/oss-s...y/2024/03/29/4

Last year there was an academic research project (sadly I can't remember who carried it out) to see if it was possible to inject bad code into the Linux kernel. They used precisely this method, offering harmless patches that corrected minor stylistic errors and seemed only pedantic at worst, but one of them created an opening into which something worse could be inserted later.

Of course they immediately informed the kernel team and the world of their success.

Isn't the University of Minnesota in 2021 ?
https://cse.umn.edu/cs/statement-cse...-april-21-2021
https://cse.umn.edu/cs/open-letter-l...-april-24-2021

2 members found this post helpful.

Yep. Their IRB probably should've had something to say about that one.