Damn. I'm on macOS and use homebrew. To my surprise I had "xz" version 6.5.1 installed on my computer!
I ran "brew upgrade" and that downgraded to version 5.4.6.
Backdoor in upstream xz/liblzma leading to SSH server compromise
551–560 of 1001 posts
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#552Potentially malicious commit by same author on libarchive: https://github.com/libarchive/libarchive/pull/1609
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#553A 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.
[deleted]
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#554Is there already a list of distributions that included the affected versions in non-prereelase channels?
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#555A 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.
Hey all, I’m the author of that PR. Just posted to Github with additional context: https://github.com/jamespfennell/xz/pull/2#issuecomment-2027...
That sucks to have people write mails to your employer...
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#556Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.
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.
750 commits... is xz able to send e-mails yet?
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#557Earlier quoted context omitted.
Hey all, I’m the author of that PR. Just posted to Github with additional context: https://github.com/jamespfennell/xz/pull/2#issuecomment-2027...
That sucks to have people write mails to your employer...
To be honest, I probably wouldn't have noticed the comments on the PR if it wasn't for that since my Github notifications are an absolute mess. Thankfully, my employer has been super supportive throughout this :D
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#558A lot of software (including https://gitlab.com/openconnect/openconnect of which I'm a maintainer) uses libxml2, which in turn transitively links to libzma, using it to load and store compressed XML. I'm not *too* worried about OpenConnect given that we use `libxml2` only to read and parse uncompressed XML… But I am wondering if there has been any statement from libxml2 devs (they're under the GNOME umbrella) about p…
This doesn't matter, if libxml2 loads .so and the library is malicious, you are already potentially compromised, as it is possible to run code on library load.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#559The two active maintainers seem to be: Lasse Collin and Jia Tan Searching DDG for "jiat0218" I came across a blog post which I found weird. Seems to be dated: 2006-05-03 Blog post: "Kuso拍賣．有靈氣的筷子 - 闕小豪" https://char.tw/blog/post/24397301 > Internet Archive link: https://web.archive.org/web/20240329182713/https://char.tw/b... > The contents of the page when translated seems to be about jiat0218 auctioning a pair of sp…
Crazy to think that the time horizon for these kinds of attacks span decades. This absolutely does not read like a coincidence. Chopsticks, little sister, "room to work hard", all sound like codewords.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#560A 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?
Build-related fixes are only treating the symptoms, not the disease. The real fix would be better sandboxing and capability-based security[1] built into major OSes which make backdoors a lot less useful. Why does a compression library have the ability to "install an audit hook into the dynamic linker" or anything else that isn't compressing data? No amount of SBOMs, reproducible builds, code signing, or banning binaries will change the fact that one mistake anywhere in the stack has a huge blast radius.
[1]: https://en.wikipedia.org/wiki/Capability-based_security