Backdoor in upstream xz/liblzma leading to SSH server compromise
791–800 of 1001 posts
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#792A lot of eyes will be dissecting this specific exploit, and investigating this specific account, but how can we find the same kind of attack in a general way if it’s being used in other projects and using other contributor names?
We should be able to produce a tar and a proof that tar was produced from a specific source code. Quote from the article: That line is not in the upstream source of build-to-host, nor is build-to-host used by xz in git. Zero Knowledge virtual machines, like cartesi.io, might help with this. Idea is to take the source, run a bunch of computational steps (compilation & archiving) and at the same time produce some kind…
I don’t think zero knowledge systems are practical at the moment. It will take over around 8 orders of magnitude more compute and memory to produce a ZKP proof of generic computation like compilation. Even 2 orders of magnitude is barely acceptable.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#793I 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.
Why not `git archive`?
Because I didn't know about it.
Although if I look at its documentation, it's already a somewhat complicate invocation with unclear effects (lots of commandline options). Git seems to not be able to do KISS.
git ls-files and tar is a simple thing everybody understands and can do without much issues.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#794Very 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…
I’m surprised there isn’t way more of this stuff. The supply chain is so huge and therefore represents so much surface area.
Imagine if sshd was distributed by PyPI or cargo or npm instead of by a distro.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#795Earlier 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?
Maybe one can get the code from here. New commits being added it seems.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#796I hope Lasse Collin is doing OK! Here is a older message from him [1] "I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see. It's also good to keep in mind that this is an unpaid hobby project. " Gi…
He came on IRC, he seemed ok. He did some cleanup of access and signed off for easter.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#797Earlier quoted context omitted.
And, Joey Hess has counted at least 750 commits to xz from that handle. https://hachyderm.io/@joeyh/112180715824680521 This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.
> If the code is complex, there could be many more exploits hiding. Then the code should not be complex. Low-level hacks and tricks (like pointer juggling) should be not allowed and simplicity and readability should be preferred.
For tools like compression programs, you’d generally prefer performance over everything (except data corruption, of course).
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#798Looks like GitHub has suspended access to the repository, which while it protects against people accidentally compiling and using the code, but certainly complicates forensic analysis for anyone who doesn't have a clone or access to history (which is what I think a lot of people will be doing now to understand their exposure).
It looks like git clone https://git.tukaani.org/xz.git still works for now (note: you will obviously be cloning malware if you do this) - that is, however, trusting the project infrastructure that compromised maintainers could have had access to, so I'm not sure if it is unmodified. HEAD (git rev-parse HEAD) on my result of doing that is currently 0b99783d63f27606936bb79a16c52d0d70c0b56f, and it does have commits peo…
Apparently there's a wayback machine for git repos and it "just coincidentally" archived this repo the day before the news broke:
https://archive.softwareheritage.org/browse/origin/visits/?o...
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#799Very 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…
[dead]
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#800Sadly this is exactly one of the cases where open source is much more vulnerable to a state actor sponsored attack than proprietary software. (it is also easier to find such backdoors in OS software but that's BTW) Why? Well, consider this, to "contribute" to a proprietary project you need to get hired by a company, go through their he. Also they have to be hiring in the right team etc. Your operative has to be in a…
> Well, consider this, to "contribute" to a proprietary project you need to get hired by a company, go through their he.
Or work for a third-party company that gets access to critical systems without any checks. See for example the incident from 2022 here: https://en.wikipedia.org/wiki/Okta,_Inc.
Or a third-party that rents critical infrastructure to the company (Cloud, SaaS solutions).