831–840 of 1001 posts
I looked at the differences between the GitHub repository and released packages. About 60 files are in a release package that are not in the repo (most are generated files for building) but also some of the .po files have changes. That's devastating. If you don't build your release packages from feeding "git ls-files" into tar, you are doing it wrong.
I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts). Would be interesting to see what's going on here; the person who did the releases has done previous releases too (are they affected?) And has commits going back to 2022 – relatively recent, but not that recent. Many are real commits with real changes, and they have commits on some…
> I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup If I recall correctly, xz can be built with both autoconf and cmake, are cmake configs similarly affected?
https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14de...
Why doesn’t GitHub force “releases” to be a simple repo tarball for sources and with binaries from GitHub actions or such… I find it incredibly ironic that a “version control” site gives no assurance of reproducible builds (nor reproducible source!!) The real villain is not the perpetrator, it is Microsoft, and it is all of us.
Because then for autoconf codebases you have to commit `./configure` or you have to require that users have autoconf installed and run `autoreconf -fi` first. Maybe autoconf-using projects should really just require that users have autoconf installed. Not that that would prevent backdoors, mind you.
This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerability to orders of magnitude, and once embraced not even large distro communities can defend you from that. A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and d…
That's technically wrong, but no surprise. Anti-systemd trolls usually don't understand technical details after all.
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 proj…
Yesterday sure was fun wasn't it :p Thanks for all your help/working with me on getting this cleaned up in Fedora.
xz --version
That's completely crazy, the backdoor is introduced through a very cryptic addition to the configure script. Just looking at the diff, it doesn't look malicious at all, it looks like build script gibberish.
Thanks to autoconf, we're now used to build scripts looking like gibberish. A perfect place to hide a backdoor.
This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerability to orders of magnitude, and once embraced not even large distro communities can defend you from that. A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and d…
> systemd's call to dlopen() liblzma library (CVE-2024-3094) That's technically wrong, but no surprise. Anti-systemd trolls usually don't understand technical details after all.
You are so quickly labeling an identifiable professional as troll, while hiding behind your throwaway identity, that I am confident readers will be able to discern.
Meanwhile let us be precise and add more facts https://github.com/systemd/systemd/pull/31550
Our community is swamped by people like you, so I will refrain from answering further provocations, believing I have provided enough details to back my assertion.
Yikes! Do you have any info on the individual's background or possible motivations?
Discussing commits that the other author has since reverted, IFUNC change with Project Zero tests, a focus on embedded, etc.:
https://www.mail-archive.com/xz-devel@tukaani.org/msg00642.h...
Trimming security reporting details:
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=af071ef7702...
Earlier quoted context omitted.
Yesterday sure was fun wasn't it :p Thanks for all your help/working with me on getting this cleaned up in Fedora.
PSA: I just noticed homebrew installed the compromised version on my Mac as a dependency of some other package. You may want to check this to see what version you get: xz --version Homebrew has already taken action, a `brew upgrade` will downgrade back to the last known good version.
xz 5.6.1 -> 5.4.6Earlier quoted context omitted.
GitHub has suspended @JiaT75's account. EDIT: Lasse Collin's account @Larhzu has also been suspended. EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page. -- EDIT: Just did a bit of poking. xz-embedded was touched by Jia as well and it appears to be used in the linux kernel. I did quick look and it doesn't appear Jia touched anything of interest in there. I also checked the…
> EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page. Why? Isn't it better to freeze them and let as many people as possible analyze the code?