| Title: Lessons learned with XZ vulnerability
Author: Solène
Date: 30 March 2024
Tags: security linux openbsd
Description: In this article I share my thoughts about the recent xz
vulnerability disclosure and what we could do to cope with it
# Intro
Yesterday Red Hat announced that xz library was compromised badly, and
could be use as a remote execution code vector. It's still not clear
exactly what's going on, but you can learn about this on the following
GitHub discussion that also links to original posts:
|
|
# What's the state?
As far as we currently know, xz-5.6.0 and xz-5.6.1 contains some really
obfsucated code that would trigger only in sshd, this only happen in
the case of:
* the system is running systemd
* openssh is compiled with a patch to add a feature related to systemd
* the system is using glibc (this is mandatory for systemd systems
afaik anyway)
* xz package was built using release tarballs published on GitHub and
not auto-generated tarballs, the malicious code is missing in the git
repository
So far, it seems openSUSE Tumbleweed, Fedora 40 and 41 and Debian sid
were affected and vulnerable. Nobody knows what the vulnerability is
doing exactly yet, when security researchers get their hands on it, we
will know more.
OpenBSD, FreeBSD, NixOS and Qubes OS (dom0 + official templates) are
unaffected. I didn't check for other but Alpine and Guix shouldn't be
vulnerable either.
|
|
# What lessons could we learn?
This is really unfortunate that a piece of software as important and
harmless in appareance got compromised. This made me think about how
could we protect the most against this kind of issues, I came to the
conclusion:
* packages should be built from source code repository instead of
tarballs whenever possible (sometimes tarballs contain vendoring code
which would be cumbersome to pull otherwise), at least we would know
what to expect
* public network services that should be only used by known users (like
openssh, imap server in small companies etc..) should be run behind a
VPN
* OpenBSD style to have a base system developed as a whole by a single
team is great, such kind of vulnerability is barely possible to happen
(on base system only, ports aren't audited)
* whenever possible, separate each network service within their own
operating system instance (using hardware machines, virtual machines or
even containers)
* avoid daemons running as root as possible
* use opensnitch on workstations (linux only)
* control outgoing traffic whenever you can afford to
I don't have much opinion about what could be done to protect supply
chain. As a packager, it's not possible to audit code of each software
we update. My take on this is we have to deal with it, xz may
certainly not be the only one vulnerable library running in production.
However, the risks could be reduced by:
* using less programs
* using less complex programs
* compiling programs with less options to pull in less dependencies
(FreeBSD and Gentoo both provide this feature and it's great)
# Conclusion
I actually have two systems that were running the vulnerable libs on
openSUSE MicroOS which updates very aggressively (daily update + daily
reboot). There are no magic balance between "update as soon as
possible" and "wait for some people to take the risks first".
I'm going to rework my infrastructure and expose the bare minimum to
the Internet, and use a VPN for all my services that are for known
users. The peace of mind will obtained be far greater than the burden
of setting up WireGuard VPNs. |