I accidentally found a security issue while benchmarking postgres changes.
If you run debian testing, unstable or some other more "bleeding edge" distribution, I strongly recommend upgrading ASAP.
@AndresFreundTec congrats and thank you for the investigation- IMO this is going to go down as the vuln of the decade. What a find.
@dgilman Unfortunately I suspect we'll see a lot more such attacks going forward, in all likelihood with more success in some cases.
@AndresFreundTec @dgilman
This is insane. I expect full-fledged articles out soon, but another interesting bit in https://news.ycombinator.com/item?id=39866275 :
"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""
This is CVE-2024-3094 for easier tracking.
@AndresFreundTec @dgilman
From the same thread:
"Fascinating. 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."
@AndresFreundTec @dgilman
The same author also made sure to point people at the compromised archives:
"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."
@AndresFreundTec And the backdoor author has been maintaining xz since 2022, so who knows what's in there.
@AndresFreundTec @richlv and the #JiaT75 hashtag
@richlv @AndresFreundTec oh, more fun from there:
My above post shows the primary domain for xz moving from tukaani.org to xz.tukaani.org. While it's hosted on github:
$ host xz.tukaani.org
host xz.tukaani.org is an alias for tukaani-project.github.io.And originally it was not:
$ host tukaani.org
tukaani.org has address 5.44.245.25 (seemingly in Finland)It was moved there in Jan of this year, as per the commit listed in my prior post. By this same person/account. This means that instead of Lasse Collin's more restrictive webpage, an account directly under the control of the untrusted account, is now able to edit the webpage without anyone else's involvement.
And larhzu adding #JiaT75 (and himself) to maintainers in Linux just a few days ago.
And:
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/ee44863ae88e377a5df10db007ba9bfadde3d314
Thanks to Hans Jansen for the original patch.
it gets better
There were a ton of patches by these two subsequently because the ifunc code was breaking with all sorts of build options and obviously caused many problems with various sanitizers.
Subsequently the configure script was modified multiple times to detect the use of sanitizers and abort the build unless either the sanitizer was disabled or the use of ifuncs was disabled. That would've masked the payload in many testing and debugging environments.The hansjans162 Github account was created in 2023 and the only thing it did was add this code to liblzma. The same name later applied to do a NMU at Debian for the vulnerable version.
Another "<name><number>
" account (which only appears here, once) then pops up and asks for the vulnerable version to be imported: […]
and
Also I saw this hans jansen user pushing for merging the 5.6.1 update in debian:
@mirabilos looking at the liblzma from 5.6.0 and 5.6.1-1 on arch Linux, allegedly vulnerable, but can't find the backdoor in the CRC functions. Anyone verified the arch build system executed the inject?
@rep I don’t do Arch, it’s infested by systemd :þ
@rep @mirabilos
https://archlinux.org/news/the-xz-package-has-been-backdoored/
As for for ssh:
_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:
ldd "$(command -v sshd)"
_
@eugen @mirabilos maybe that defeats the vector, but the arch builds are not vulnerable because the during build the file $srcdir/debian/rules is not present. Arch just wasn't even targeted.
@mirabilos @eugen for sure needs further research, but probably rolling release distros like arch are too hard/annoying to target with exploit payloads anyways. Would have to be a different vector on those. Either way in this case the backdoor wasn't built/present on arch.
@richlv @AndresFreundTec @dgilman It does not affect FreeBSD at all. Simply because this person was targeting a specific OS.