Red Hat Issues Urgent Alert For Fedora Linux Users Due To Malicious Code (betanews.com) 83
BrianFagioli shares a report from BetaNews: In a recent security announcement, Red Hat's Information Risk and Security and Product Security teams have identified a critical vulnerability in the latest versions of the 'xz' compression tools and libraries. The affected versions, 5.6.0 and 5.6.1, contain malicious code that could potentially allow unauthorized access to systems. Fedora Linux 40 users and those using Fedora Rawhide, the development distribution for future Fedora builds, are at risk.
The vulnerability, designated CVE-2024-3094, impacts users who have updated to the compromised versions of the xz libraries. Red Hat urges all Fedora Rawhide users to immediately cease using the distribution for both work and personal activities until the issue is resolved. Plans are underway to revert Fedora Rawhide to the safer xz-5.4.x version, after which it will be safe to redeploy Fedora Rawhide instances. Although Fedora Linux 40 builds have not been confirmed to be compromised, Red Hat advises users to downgrade to a 5.4 build as a precautionary measure. An update reverting xz to 5.4.x has been released and is being distributed to Fedora Linux 40 users through the normal update system. Users can expedite the update by following instructions provided by Red Hat. Further reader submissions: xz/liblzma Backdoored, Facilitating ssh Compromise;
Malicious Code Discovered in Popular XZ Utils.
The vulnerability, designated CVE-2024-3094, impacts users who have updated to the compromised versions of the xz libraries. Red Hat urges all Fedora Rawhide users to immediately cease using the distribution for both work and personal activities until the issue is resolved. Plans are underway to revert Fedora Rawhide to the safer xz-5.4.x version, after which it will be safe to redeploy Fedora Rawhide instances. Although Fedora Linux 40 builds have not been confirmed to be compromised, Red Hat advises users to downgrade to a 5.4 build as a precautionary measure. An update reverting xz to 5.4.x has been released and is being distributed to Fedora Linux 40 users through the normal update system. Users can expedite the update by following instructions provided by Red Hat. Further reader submissions: xz/liblzma Backdoored, Facilitating ssh Compromise;
Malicious Code Discovered in Popular XZ Utils.
Reaction from OpenSUSE (Score:5, Interesting)
OpenSUSE has a more radical recommendation [opensuse.org]:
For our openSUSE Tumbleweed users where SSH is exposed to the internet we recommend installing fresh, as it’s unknown if the backdoor has been exploited.
Re: (Score:2)
I used to point out that, if Linux were on hundreds of millions of desktops, it, too, would be under assault from large numbers of motivated hackers from sketchy countries, and would not be anywhere near as bullet proof as POMSPPP (Pee-ers On Microsoft Products Proudly Pontificated.)
You were security through obscurity. Welcome to the edge of the big boys club.
Re:You should read up on... (Score:4, Interesting)
On top of that, Linux didn't have Microsoft Office or Outlook, whereas Windows also had Outlook Express and a web browser that was literally baked into the operating system. The world's easiest door to crack open, and it was, constantly, millions of times a day, causing untold damage to systems everywhere quite literally. With those kinds of odds, why would any competent hacker bother to trespass laboriously on Linux systems one at a time unless they were professional spearphishing?
Re: (Score:2)
Agreed, but the argument is still a valid one. There's fragmentation in the implementations. Debian stable, for example, didn't have the backdoor. Some distros are big, but we're very far from a monoculture still.
Re: (Score:2, Informative)
... the Linux propaganda posted here during the late 90s-early 2000s by the Zealots.
Got some anger issues?
SSHD is not Linux, nor is XZ. Good luck finding any remote connection software that has never had an exploit (it must be quite obscure). This kind of software has a huge bullseye on it.
SSHD for Windows. https://learn.microsoft.com/en... [microsoft.com]
XZ for Windows. https://sourceforge.net/projec... [sourceforge.net]
SystemD for Windows. https://devblogs.microsoft.com... [microsoft.com]
Re: (Score:1)
Re: (Score:1)
xz is not Linux, but whatever.
This was an attack by someone with commit privileges in the project. Would MSFT magically prevent something like that? I am fascinated to find out how.
Re:So much for that, Zealots. (Score:5, Interesting)
This was an attack by someone with commit privileges in the project. Would MSFT magically prevent something like that? I am fascinated to find out how.
Fair, but Microsoft actually has a good idea of the real identity of people committing to Microsoft code. Various forms of ID, background checks etc. Jia Tan (JiaT75) is just a name with no background, nobody seems to know who they are, what they look like, where they live, or who pays their salary.
Debian requires verified real identities to become a developer, but I'm not aware of other non-commercial projects that do. Maybe identity verification should become the norm.
Re: (Score:2)
Fair, but Microsoft actually has a good idea of the real identity of people committing to Microsoft code.
Maybe. Maybe not. I'm sure they have a very good idea of the real identity of people they pay to write code for their products. But they also use a ton of open-source code themselves. And I'm guessing they use contractors for a fair bit of their coding too, whose identities and loyalties might not be as solidly known as employees'.
Maybe identity verification should become the norm.
I think it
Re: (Score:2)
Fair, but Microsoft actually has a good idea of the real identity of people committing to Microsoft code.
Maybe. Maybe not. I'm sure they have a very good idea of the real identity of people they pay to write code for their products. But they also use a ton of open-source code themselves. And I'm guessing they use contractors for a fair bit of their coding too, whose identities and loyalties might not be as solidly known as employees'.
They still know the real-world identity. More importantly, management is a lot more top-down at MS. If I want to exploit the MS equivalent of xz I need to not only get my agent hired and assigned to the right team, but they need to wait until they're assigned to some task/bug where there's an opportunity to slip something in.
With open source, you just start contributing to the area you're interested in, wait until you've built up some trust, and then slip in the nasty.
I'd be shocked if China and Russia (and
Re: (Score:2)
"The Linux"? Why trust a rant by someone who can't write in English.
Linux is extremely secure, if set up correctly. And, if set up correctly, the xz exploit would have little or no impact. It would not make a properly secured machine vulnerable.
Re: So much for that, Zealots. (Score:2)
Re: So much for that, Zealots. (Score:1)
Not against this exploit, if you read the details you would know this is an intentional back door built into xz that affects ssh. Basically the attacker had committed his key obfuscated several years now to the official repos, which allows that entity root access to any ssh exposed system.
Re: (Score:2)
Seems reasonable. Details of what the backdoor does have not been fully analyzed and published.
So for all we know; it's not necessarily only SSHD affected. The payload if exploited could contain a persistence mechanism and/or rootkits. The injection is sophisticated enough as it is that it probably comes from state-supported actors, and all bets are off.
Re: (Score:3)
The exploit specifically checks for being run via /usr/bin/sshd, and only on distros patched with systemd-specific code that's not present in either openssh's upstream nor in openssh-portable. It's also specific to amd64 and glibc.
Re: (Score:2)
What the hell is systemd code doing in openssh?
Re: (Score:2)
And the libsystemd crap is even in Devuan sshd! What the fuck? Do I now need to compile OpenSSH from sources myself to get a clean non-backdoored version?
It looks like a lot of people have gotten lazy, fat and dumb.
Re: (Score:3)
The lwn article also goes into how some of the exploit's payload code is injected into sshd via the linker. (So it's kinda of doing the same trick as Microsoft's Detours library, and kinda not.) Worth a read if you're into that kind of thing.
Re: (Score:3)
Hmm. With ldd:
- Debian 10 (oldoldstable): No libsystemd in sshd
- Debian 11 (oldstable): libsystemd and liblzma in sshd
- Debian 12/Devuan Daedalus (stable): libsystemd in sshd, but no liblzma
Seems there is some information still missing. Also seems Devuan still has systemd crap in there. My trust in Devuan just took a real hit.
Re: (Score:3)
liblzma is linked in to sshd in Debian 12, but not a vulnerable version.
$ ldd /usr/sbin/sshd | grep liblzma /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f333d5f0000)
liblzma.so.5 =>
$ dpkg -l liblzma5
ii liblzma5:amd64 5.4.1-0.2 amd64 XZ-format compression library
ii liblzma5:i386 5.4.1-0.2 i386 XZ-format compression library
Re: (Score:3)
FYI it has already been downgraded back to 5.4.5 in Trixie, aka testing.
The version reports as '5.6.1+really5.4.5-1'.
Re: (Score:2)
No lzma in sshd on my Debian 12 system:
/usr/sbin/sshd | grep lzma
~# ldd
~#
Ah, I know. This is a non-systemd Debian 12 installation. Apparently that causes liblzma to not get pulled in. Interesting.
Re: (Score:2)
That's correct. sshd doesn't directly require liblzma, but libsystemd does. So if it's not linked against libsystemd, it won't pull in liblzma.
Re: (Score:2)
Actually sshd _is_ linked against libsystemd in this installation. But for whatever reason libsystemd does not pull in liblzma. Probably a differences in libsystemd.
Re: (Score:2)
Same in Mint 21.3, but even older (safe) versions:
ii liblzma5:amd64 5.2.5-2ubuntu1 amd64 XZ-format compression library
ii liblzma5:i386 5.2.5-2ubuntu1 i386 XZ-format compression library
Fedora tends to be bleeding edge (which is why it has the latest and vulnerable version), one of the reasons I am not fond of it. The other now being the RedHat association (which really turns me off now).
Re: (Score:2)
According to the linked lwn article, some distros patch in support for notifying systemd about incoming connections. (My guess, probably for session management purposes.) libsystemd depends on lzma so that's what the exploit is targeting.
What's weird here is the Linking process is designed so that lzma is able to Backdoor it by just being loaded. The Call SSHD needs to make does Not have anything to do with the lzma library. The only thing the library needs to do to post that notification is send a si
Re: (Score:2)
Yes, shared libraries can have initializers and finalizers. That's built in to the UNIX shared library spec. Just loading a shared library can execute arbitrary code.
Re: (Score:2, Interesting)
> Details of what the backdoor does have not been fully analyzed and published
Yes, they have. From the initial report on oss:
> The payload if exploited could contain a persistence mechanism and/or rootkits.
No shit. Here you have a backdoor'ed sshd (a program installed by default on any
Re: Reaction from OpenSUSE (Score:1)
It hasnâ(TM)t been completely analyzed but we know by now that it is basically an embedded key that allows the attacker to authenticate himself to any system running the affected code.
Re: (Score:2)
So a NOBUS backdoor? I.e. nobody else can use it? That would indicate a new level of sophistication. Not necessarily by the guy that placed it, but by whoever designed it. Seems this is a pretty big wake-up call for some people FOSS world that have gotten too comfortable. Still impressive that it got caught before it could do any real damage. Also a nice reference case for a FOSS supply-chain attack.
Re: (Score:1)
Well, ‘nobody’ pointing at a certain Asian government, rendering some 90% of servers with exposed SSH open to root access which can be used to disable most of the Internet in case of need.
Not sure yet if you can deduce the private key from the embedded code, but the code was embedded in ‘tests’, not in plain source code. Basically they published a ‘broken’ xz binary pretending it was a test on how the program should handle broken files. However during compile time, the te
Re: (Score:2)
Seriously, if you have nothing relevant to say, just shut up.
Re: (Score:2)
Did you reply to the wrong post? The post you are replying to is definitely relevant and informative.
Re: (Score:1)
No, gweihir is a Chinese shill, any criticism of China or communism and he will have an outrageous response like that.
Catastrophe potentially averted (Score:5, Informative)
The backdoored version of xz wasn't in widespread use just yet, but that may have only been weeks or days away. We're lucky that Andreas Freund got curious about some performance anomalies and investigated [lwn.net].
Re:Catastrophe potentially averted (Score:5, Interesting)
We can't know for sure that crisis has been averted. The dev who injected this has more than 2 years of commit history on XZ and other projects.
There are a ton of binary "test blobs" they uploaded over the years. They even made patches to a Google project that in retrospect seem to be designed to prevent Detection of the backdoor they were introducing later into XZ, so maybe older versions of XZ have deliberate vulnerabilities or exploit vectors as well, and they just made a mistake with the latest one.
Re:Catastrophe potentially averted (Score:5, Funny)
So it was a set of eyes and not many eyes
It was, quite possibly, Five of them.
Re: (Score:2)
Re: (Score:3)
>"So it was a set of eyes and not many eyes"
Beats the hell out of NO eyes, doesn't it?
Re:Catastrophe potentially averted (Score:4, Interesting)
So the question is... who really employs this developer - one of the "official unofficial" Russian cyber-thug gangs, or a US 3-letter agency?
Re: (Score:2)
Aren't the Chinese hackers generally a bit more competent?
The fact that the patches were badly broken and utterly inept sounds more like the work of a rival OS developer.
Re: (Score:1)
No, sounds exactly like a government job. Even in China the government does not pay well (which means nobody in China gets paid well). This is exactly what I would expect from an incompetent government employee. The obfuscation path was relatively clever and they would’ve gotten away with it if they actually tested their own code.
Re: (Score:2)
So it's all down to those meddling kids and their dog.
Re: (Score:2)
Microsoft is a likely suspect.
Re: (Score:2)
Yep, hence the "potentially" in the subject line.
Re: Who was the shithead dev that did this crime? (Score:1)
Re: (Score:2)
Spoiler: "As of 9:00 PM UTC, GitHub has suspended JiaT75’s account. Thanks? They also banned the repository, meaning people can no longer audit the changes made to it without resorting to mirrors. Immensely helpful, GitHub. They also suspended Lasse Collin’s account, which is completely disgraceful."
Re: (Score:3)
There is no intelligent life left at GitHub since MicroShit bought it.
systemd (Score:2)
Never felt so good for not running systemd at all. I suppose maybe having one daemon controlling so much of the system does have some downsides.
Re: (Score:2)
If someone rewrote systemd using formal methods, the same way SEL4 is written, then there would be very few downsides to it. The problem is that the defect density is higher than one would like for a critical application that does control much of the system.
Re: (Score:2)
As a counterpoint, this vulnerability was in liblzma, which is part of the xz package. The target of the vulnerability was the sshd, introducing a backdoor into it via interaction with liblzma using ifuncs. Normally, sshd wouldn't interact with liblzma, but Debian, Red Hat and others patched their sshd to call it, specifically to send notifications to libsystemd.
Therefore, this isn't really a code flaw in systemd, it's a flaw in aggregation resulting from the presence of systemd. So regardless of how wel
Re: (Score:1)
except the very existence of systemd means many tie-ins to inject malware. It's not the Unix way, it's something worthy of a proprietary laptop OS and causes no end of troubles when used on farms of hundreds or thousands of servers.
Re: (Score:2)
I, of course, agree. I don't understand why this aggregation argument didn't get more play when Lennart was trying to get this in to distros in the 2013 time frame. Perhaps a sample vulnerability like this needed to be shown to people.
Considering his model was the OSX launchd, 'proprietary laptop OS' sounds very apropos.
Re: (Score:1)
Speaking as someone who also adminned macosx servers until we got rid of them a couple years ago, launchd doesn't have 1/100 the issues systemd does for impeding startup, not logging, bogging proper startup / shutdown, and managing dozens of other services that should be separate. It's never made a server a mess that needed hours of troubleshooting recovery.
systemd should be an option for zoomers with laptops or home computers.
Re: (Score:2)
I agree that systemd makes a pig's war of everything.
Re: systemd (Score:2)
Deceptively written (Score:3)
If by "Red Hat's Information Risk and Security and Product Security teams have identified", you mean "Red Hat was informed", then sure. But Red Hat didn't identify anything except email in their inbox.
Re: (Score:1)
Sorry to provide data points that contradict your anti-Red Hat narritive, but I personally know several Red Hat employees who discovered security issues that became CVEs in projects you have used (or at least heard of). In this case, the person who discovered the issue is not from Red Had, but he appears to have consulted a Red Hat employee, Florian Weimer, about the specifics of the exploit, as he explained in his mailing list post.
But, yeah, don't let facts stop you from hating on Red Hat.
Re: Deceptively written (Score:1)
Quoting the actual Redhat announcement rather than the badly edited summary: "Yesterday, Red Hat Information Risk and Security and Red Hat Product Security *learned* that..." (my emphasis)
WHY wasn't 40 compromised? (Score:2)
The linked article from betanews and Red Hat's blog post say 40 was not found to be compromised, strongly implying that in their build system even if you got the 5.6.x version, the payload didn't seem to have made it into the package, even if you got that version.
Other sources, Fedora Magazine in particular, says if you got the "testing" updates, that is if you got the 5.6.x package, then it was in fact compromised. It appears the 5.6.x version was pulled form Fedora 40's testing builds altogether very earl
Re:WHY wasn't 40 compromised? (Score:5, Informative)
In case anyone else is curious, I found a detailed explanation here on a Fedora mailing list:
https://lists.fedoraproject.or... [fedoraproject.org]
Essentially to get around warnings, the 5.6.0 package had effectively avoided the exploit, but the very determined attacker actually made a new release, 5.6.1, and convinced the maintainers to remove the workaround. The Beta freeze in 40 meant only the 5.6.0 package ever made it even to the "testing" updates to version 40.
Re: (Score:3)
Isn't it nice to be able to find that kind of info about how software was built? Open Source tends to expose that information. You won't find that with proprietary software.
Re: (Score:2)
Indeed. In a closed-source compromise, the best you get is some relative abstract analysis months later. Usually you do not even get that and software makers can just continue their shoddy practices. Also nothing like the reaction speed that FOSS has.
Re: (Score:2)
Yeah. I actually chose to upgrade my home PC to Fedora 40 friday morning. It was literally upgrading as this news hit.
It was very nice to have all the bodhi logs *and* my dnf logs tell me I never installed a vulnerable version. Otherwise, I'd be doubting it regardless of what any virus scan or other tool said.
Re: (Score:2)
And note, since then, the word is Fedora 40 actually *was* affected, if only for a wile, if you were using the testing updates repo.
https://lists.fedoraproject.or... [fedoraproject.org]
Fedora, Arch, and Gentoo are like Node.js packages (Score:2)
Worst exploit Iâ(TM)ve ever seen (Score:2)
Re: Worst exploit Iâ(TM)ve ever seen (Score:2)
Where is the REAL news? (Score:2)
Whys are there only announcements? Why isn't there a link to actual news about this? In some of the comments, I find some very interesting pieces of information, such as the pseudonym of the developer that submitted the changes... but not a single "article" that is linked answers even a single question. WTF?
This is worse than Headline News.
Exposes the need for secure, reproducible builds (Score:2)
0. Builds should be remotely reproducible and built from source randomly on any endpoint to verify binary artifacts are correct.
1. Binary build environments should be doing HIDS/HIPS-like integrity scans before and after a build, and antimalware scans during to make sure that an installation isn't able to go out and touch parts of the systems it shouldn't have access to. If some shit(tm) happens in the build, there should be VirusTotal-like data to demonstrate what went weird.
2. SELinux MLS should be depl