While the backdoor was inactive (and thus harmless) without inserting
a small trigger code into the build system when the source package was
created, it's good to remove this anyway:
- The executable payloads were embedded as binary blobs in
the test files. This was a blatant violation of the
Debian Free Software Guidelines.
- On machines that see lots bots poking at the SSH port, the backdoor
noticeably increased CPU load, resulting in degraded user experience
and thus overwhelmingly negative user feedback.
- The maintainer who added the backdoor has disappeared.
- Backdoors are bad for security.
Special author: Jia Tan was a co-maintainer in 2022-2024. He and
the team behind him inserted a backdoor (CVE-2024-3094) into
XZ Utils 5.6.0 and 5.6.1 releases. He suddenly disappeared when
this was discovered.
At least in Debian there's already the inevitable discussion about a supposed opportunity for "finally" moving to zstd. Which to me, frankly, feels a bit like getting out of the frying pan and into the fire, or what I think Arch (yuck) did years ago. That's not because I'm so much into xz. It's kind of funny there's a possible Debian connection, of all things, considering that quite a lot authorities and services in areas like China, Russia or Iran are recently migrating, for obvious reasons, from Windows/Mac to more or less home-made (~styled) Linux distributions, that just often happen to be based on Debian. I don't think this is too popular in English speaking countries in particular, but then I really didn't want to chime in on the speculations. ;P
This has to go on the list of "best understatements ever", along with that famous captain's announcement when an ash cloud knocked out all four engines.
Systemd's ridiculous inability to manage daemons correctly, like every other init system on the planet, necessitated debian, redhat, and others patching ssh, just so systemd could reliably start ssh.
Which is what enabled this vulnerability to be viable.
I'm relieved that the GitHub repo has finally been restored. I was just about to make a commit to fix our liblzma dependency, which would have required a vcpkg overlay to use a different upstream repo.
Maybe we need an international NGO/co-op to provide essential services for small, essential FOSS projects such as security comms, security audits, build infrastructure, testing, best practices, background investigations, and so forth.
The "one guy's little piece of code holding up the world" is a SPOF and much easier to attack than if they had some help and automation.
> They will turn FOSS into a walled garden, as if contributing to projects was not a pain already.
The only thing in here that has potential negative impact are the background investigations, but it might be reasonable to have an independent third party that offers this as a service for project leads.
