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:
       
 (HTM) Discussion about xz being compromised
       
       # 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.
       
 (HTM) Gentoo security advisory (unaffected)
       
       # 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.