Re: [PLUG] - attack on sshd via xz => More XZ Libs malware info
I also appreciate the heads-up on this as I literally do have better things to do than spend an hour every day reviewing security exploit mailing lists. 😉 Coming from a FreeBSD background this is why I have never liked the "yum install" and apt-get" things that the Linux userbase take for granted. Under FreeBSD you have ports and you install Unix software the way God intended Unix software to be installed, "make install" Then you actually get CHOICES on how to build. Why does xz need to run the test sets anyway during building? How stupid! 90% of what it's being built on ix s86 it's going to result in the same binary. Note that this has happened before: https://lwn.net/Articles/853717/ The most troubling aspect is that there's too little supervision of changes in projects. Ted -Original Message- From: PLUG On Behalf Of MC_Sequoia Sent: Friday, April 5, 2024 3:21 PM To: Portland Linux/Unix Group Subject: Re: [PLUG] - attack on sshd via xz => More XZ Libs malware info Firstly, thank you for making me aware of this! "It also helps that it really only made it to the public through Debian unstable and testing." According to this article, https://thenewstack.io/malicious-code-in-linux-xz-libraries-endangers-ssh/, xz is a "core Linux compression utility". I wasn't aware. So any unstable/testing distro is vulnerable. "Red Hat was first to break the news of the boobytrap." Here's the pkg & version info for those who want to do a quick system check. Package: xz-utils Version: 5.6.1+really5.4.5-1 Refer to full Debian bug report => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024&utm_source=the+new+stack&utm_medium=referral&utm_content=inline-mention&utm_campaign=tns+platform The most troubling aspect of this malware is this: "I count a minimum of 750 commits or contributions to xz by Jia Tan, who backdoored it. This includes all 700 commits made after they merged a pull request in Jan 2023, at which point they appear to have already had direct push access, which would have also let them push commits with forged authors. Probably a number of other commits before that point as well." So there might be more malware lurking and there might be more security fallout.
Re: [PLUG] - attack on sshd via xz => More XZ Libs malware info
Looks like there is no xz-utils in Arch, and it's not installed by default in Pop_OS, FWIW... On Sat, Apr 6, 2024 at 2:24 PM Ted Mittelstaedt wrote: > I also appreciate the heads-up on this as I literally do have better > things to do than spend an hour every day reviewing security exploit > mailing lists. 😉 > > Coming from a FreeBSD background this is why I have never liked the "yum > install" and apt-get" things that the Linux userbase take for granted. > Under FreeBSD you have ports and you install Unix software the way God > intended Unix software to be installed, "make install" > Then you actually get CHOICES on how to build. Why does xz need to run > the test sets anyway during building? How stupid! 90% of what it's being > built on ix s86 it's going to result in the same binary. > > Note that this has happened before: > > https://lwn.net/Articles/853717/ > > The most troubling aspect is that there's too little supervision of > changes in projects. > > Ted > > -Original Message- > From: PLUG On Behalf Of MC_Sequoia > Sent: Friday, April 5, 2024 3:21 PM > To: Portland Linux/Unix Group > Subject: Re: [PLUG] - attack on sshd via xz => More XZ Libs malware info > > Firstly, thank you for making me aware of this! > > "It also helps that it really only made it to the public through Debian > unstable and testing." > > According to this article, > https://thenewstack.io/malicious-code-in-linux-xz-libraries-endangers-ssh/, > xz is a "core Linux compression utility". I wasn't aware. > > So any unstable/testing distro is vulnerable. "Red Hat was first to break > the news of the boobytrap." > > Here's the pkg & version info for those who want to do a quick system > check. > > Package: xz-utils > Version: 5.6.1+really5.4.5-1 > > Refer to full Debian bug report => > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024&utm_source=the+new+stack&utm_medium=referral&utm_content=inline-mention&utm_campaign=tns+platform > > The most troubling aspect of this malware is this: > > "I count a minimum of 750 commits or contributions to xz by Jia Tan, who > backdoored it. > > This includes all 700 commits made after they merged a pull request in Jan > 2023, at which point they appear to have already had direct push access, > which would have also let them push commits with forged authors. Probably a > number of other commits before that point as well." > > So there might be more malware lurking and there might be more security > fallout. > > > > >
Re: [PLUG] attack on sshd via xz
On 4/5/24 10:36, wes wrote: > I'm surprised to see that no one has mentioned this on PLUG yet, though > it's been flying around the rest of the tech sphere on the internet pretty > heavily over the last week. I will share it here in case any list member > hasn't seen it yet elsewhere and if anyone is interested in this subject. > > The short version is, someone (potentially many someones) attempted to > insert malicious code into the Linux pipeline which would have resulted in > them being able to log in to any system running that code without > authorization. The attempt was caught before it reached any major level of > distribution and stopped, but the fact that it even got that far is > alarming. > > Here is a NYT article covering the sequence of events in a pretty > approachable way: > > https://www.nytimes.com/2024/04/03/technology/prevent-cyberattack-linux.html > > And for those who do not feel motivated to create an account on the NYT > website: > > https://archive.ph/tc9bN > > Interestingly, for those of us that use Slackware64-15.0 Linux (stable), the xz debacle was a non-issue. Even for Slackware64-current, it was a non-issue, but to be on the save side, xz was rebuilt and patched with clean code: ChangeLog Fri Mar 29 20:39:11 UTC 2024 a/xz-5.6.1-x86_64-2.txz: Rebuilt. Seems like a good idea to build this from a git pull rather than the signed release tarballs. :-) The liblzma in the previous packages were not found to be vulnerable by the detection script, but I'd rather not carry the bad m4 files in our sources. Here's a test script for anyone wanting to try it: if hexdump -ve '1/1 "%.2x"' /lib*/liblzma.so.5 | grep -q f30f1efa554889f54c89ce5389fb81e700804883ec28488954241848894c2410 ; then echo probably vulnerable else echo probably not vulnerable fi Sat Mar 30 18:08:12 UTC 2024 a/xz-5.6.1-x86_64-3.txz: Rebuilt. [PATCH] CMake: Fix sabotaged Landlock sandbox check. We don't build with CMake (yet), but it doesn't hurt to apply this. Ya'll can keep yer fancy pants linux distros with yer systemd, dpkg/apt/yum and other silliness. The Year of the Slackware Linux Desktop 1993 - 2024 -Ed
Re: [PLUG] attack on sshd via xz
"Ya'll can keep yer fancy pants linux distros with yer systemd, dpkg/apt/yum and other silliness." Thanks! I will! It wasn't a problem for me! =)
Re: [PLUG] - attack on sshd via xz => More XZ Libs malware info
"The most troubling aspect is that there's too little supervision of changes in projects." Nope! It's far less about supervision and far more about process. Especially in the FOSS world, which relies heavily on peer review & the user community to ferret out bad code as happened in this cause by someone doing database benchmark tests and noticed the SSH logins were taking much longer than normal. If you've ever found yourself supervising a bad process, you'd know this beyond a shadow of a doubt. I can't tell you the number of jobs, where as a technical person, I did way more work fixing bad & broken processes than I did fixing bad & broken workers, with the exception of the occasional incompetent, lazy or bad worker who doesn't want to follow process or is unable to. In which case, you set them free to find another job! =)
Re: [PLUG] - attack on sshd via xz => More XZ Libs malware info
Ah but I suspect in all of your supervision of employees you never had an employee who was under contract from the Russian military, and probably being paid millions of rubles or whatever they are using there, at the same time you were supervising them, who's job was to pwn the project for his actual employers needs instead of your needs. Such an employee would have been the perfect one to supervise, and he would have also insured that the process was working perfectly as well. The very last thing he would want is for you to get involved to fix something. FOSS operates because it's NOT crapped up by 6 committee meetings and a dozen code reviews which your typical programmer hates with a passion. The process works or Linux wouldn't be good enough today to run mission critical stuff. In this case it was one PERSON operating in that working environment who's job was to subvert it. Letting him into the party to play with the toys was not done properly, or as a bad actor he would have been screened out. It's not process - it's absolutely the supervision. A commercial org with Agile development and code review and process up the wazoo ...well that's Microsoft. And their process doesn't deliver any better code as witnessed by all the problems with the March security update Ted -Original Message- From: PLUG On Behalf Of MC_Sequoia Sent: Saturday, April 6, 2024 5:28 PM To: Portland Linux/Unix Group Subject: Re: [PLUG] - attack on sshd via xz => More XZ Libs malware info "The most troubling aspect is that there's too little supervision of changes in projects." Nope! It's far less about supervision and far more about process. Especially in the FOSS world, which relies heavily on peer review & the user community to ferret out bad code as happened in this cause by someone doing database benchmark tests and noticed the SSH logins were taking much longer than normal. If you've ever found yourself supervising a bad process, you'd know this beyond a shadow of a doubt. I can't tell you the number of jobs, where as a technical person, I did way more work fixing bad & broken processes than I did fixing bad & broken workers, with the exception of the occasional incompetent, lazy or bad worker who doesn't want to follow process or is unable to. In which case, you set them free to find another job! =)
