mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

336K
active users

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.

openwall.com/lists/oss-securit

www.openwall.comoss-security - backdoor in upstream xz/liblzma leading to ssh server compromise

@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.

Rihards Olups

@AndresFreundTec @dgilman
This is insane. I expect full-fledged articles out soon, but another interesting bit in news.ycombinator.com/item?id=3 :

"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.

news.ycombinator.comVery annoying - the apparent author of the backdoor was in communication with me... | Hacker News

@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 And the backdoor author has been maintaining xz since 2022, so who knows what's in there.

tukaani.org/about.html

@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.

GitHubliblzma: Add ifunc implementation to crc64_fast.c. · tukaani-project/xz@ee44863The ifunc method avoids indirection via the function pointer crc64_func. This works on GNU/Linux and probably on FreeBSD too. The previous __attribute((__constructor__)) method is kept for compatib...

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
archlinux.org/news/the-xz-pack
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)"_

archlinux.orgArch Linux - News: The xz package has been backdoored

@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.

@rep @eugen not vulnerable to this one, but the author shows deep understanding of intricate code details and has 700+ commits in xz, who knows what else they buried…

@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.

@eugen @rep nobody directly links openssh to liblzma; some distros (against upstream’s design!) link it to systemd which does, though

@richlv @AndresFreundTec @dgilman It does not affect FreeBSD at all. Simply because this person was targeting a specific OS.