Linux Supply Chain Attach Discovered in SSH CVE-2024-3094 [YouTube Release]

Additional Resources:

AndresFreundTec Mastadon post Infosec Exchange

GitHub FAQ on the xz-utils backdoor xz-utils backdoor situation · GitHub

Openwall OSS Post oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise

CVE-2024-3094 NVD - CVE-2024-3094

Kali Linux Tweet

Connecting With Us

Lawrence Systems Shirts and Swag



Amazon Affiliate Store
:shopping_cart: Lawrence Systems's Amazon Page

UniFi Affiliate Link
:shopping_cart: Ubiquiti Store

All Of Our Affiliates that help us out and can get you discounts!
:shopping_cart: Partners We Love – Lawrence Systems

Gear we use on Kit
:shopping_cart: Kit

Use OfferCode LTSERVICES to get 10% off your order at
:shopping_cart: Tech Supply Direct - Refurbished Tech at Unbeatable Prices

Digital Ocean Offer Code
:shopping_cart: DigitalOcean | Cloud Infrastructure for Developers

HostiFi UniFi Cloud Hosting Service
:shopping_cart: HostiFi - UniFi Cloud Hosting

Protect you privacy with a VPN from Private Internet Access
:shopping_cart: Buy VPN with Credit Card or PayPal | Private Internet Access

:moneybag: lawrencesystems | creating Tech Tutorials & Reviews | Patreon

0:00 - Intro
0:48 - How the backdoor was discovered
2:11 - Security Vulnerability Details
4:56 - Open Source Security

This one came real close to affecting me. I run arch and had the affected xz package for a little while. Thankfully for me, so far it looks like this was going after deb and rpm package managers exclusively. Obscurity has some practical security advantages. Hopefully it stays that way with more scrutiny.

A lot of ink has been spilled on this topic, but I’ll give my thoughts here. Maybe this can be an open journal for me to think through my choice for rolling release. It’s been on my mind the last 24 hours.

I like rolling releases for a number of good reasons, but there are two big concerns. The potential for more bugs and supply chain attacks. The bugs thing hasn’t been an issue for me given my setup. I snapshot, run minimal mainline software, and update once a month - so not even as frequently as some point release setups, or auto update setups. Bugs just aren’t an issue for me.

My concern is much more about supply chain attacks like this one. We all are at risk of supply chain attacks but a rolling release will typically get them first, assuming it is upstream supply chain attack. I don’t know how to dodge this with my current setup beside run as little software on my host OS as possible and containerize like crazy. I only have 220 packages on my host server OS, but still got caught with this one. I can reduce my attack surface only so much, xz is just too foundational.

So I am mulling over my choice for using a rolling release for my host OS. In containerized or vm environments where snapshots are available, I think a rolling release is a solid choice. But for the host OS, I wonder if debian stable is a better choice just for this one relatively small risk exposure. I don’t like the idea of doing big upgrades every two years and to a lessor extend always being behind on features. Plus, I like arch’s assume nothing policy on everything, but that is small potatoes. … At this point I think doing nothing is the best course of action, but if this sort of thing happens more frequently to the 220 packages I completely rely on I may have to strongly reconsider my host OS. Changing out my desktop OS would be harder, but I think fedora would be my likely new home. Which would also potentially suffer from the leading edge problem here. I don’t know if I could do debian stable for my workstation. Anyway, that is something I’ll push off until or if this upstream threat model becomes more common.

I think that helped me think this through. Feel free to tell me where my thinking is wrong.

Even that a server reports xz version 5.2.2 let’s say, the new pulled Docker images used for developing purposes, use system wide xz libs or use the latest version?