This headline is so egregiously sensationalist.

The XZ backdoor never made it to Debian stable. It is "still lurking in docker images" because Debian publishes unstable testing images, under a tag that is segregated from the stable release tags. You can find vulnerable containers for literally any vulnerability you can imagine by searching for the exact snapshot where things went wrong.

And then downstream projects, if they choose to, can grab those images and create derivatives.

Basing your images on an experimental testing version of Debian and then never updating it is an obvious mistake. Whether XZ is backdoored is almost irrelevant at that point, it's already rotting.

> Upon discovering this issue, Binarly immediately notified the Debian maintainers and requested removal, but the affected images remain in place.

It is generally considered inappropriate to remove artifacts from an immutable repository for having a vulnerability. This wasn't even done for vulnerable Log4j versions in Maven repositories, despite Log4shell being one of the most potent vulnerabilities in history. It would just break reproducible builds and make it harder to piece together evidence related to the exploit.

▲

Analemma_ 3 days ago | parent | next [-]

I have a feeling a lot of users just reflexively upvote any story about security vulnerabilities without checking if the contents have any meat at all. It's a well-intentioned heuristic, but unfortunately it's easily exploited in practice, because there are a whole bunch of C- and D-list security consultancy firms who use blogspam about exaggerated threats to get cheap publicity.

This post is a classic example and should've been buried quickly as such. You wouldn't upvote a LinkedIn "look at what MyCorp has been up to!" post from a sales associate at MyCorp, a lot of this infosec stuff is no different.

▲

torgoguys 3 days ago | parent [-]

I'm the one who submitted this link. (I have zero affiliation with the authors). What you say is fair enough, but I thought the article an interesting data point nonetheless. In particular, I found it interesting how a vulnerability: 1) with a tiny window during which it was published, 2) of very high potential severity, and 3) with SO MUCH publicity surrounding it could still be lingering where you might accidentally grab it. The threat isn't giant here, but I saw it as just today's reminder to keep shields up.

	▲	soneil 2 days ago \| parent [-]
		It'd be some fluke of an accident. You'd need to be targeting not only debian:testing/unstable, but specifically debian:testing-20240311. And then - making sure not to apt upgrade at any point so you don't accidentally get any updates from the last 18 months - you'd need to also install openssh-server to avail of the backdoor, plus a service manager because running sshd in the foreground killswitches said backdoor. And then don't forget to expose the ssh port otherwise our effort is wasted. The most realistic way to hit this would be to have built an image 18 months ago, on top of :testing or :unstable, and then not update or rebuild it at any time in those 18 months - in which case removing anything from the repo wouldn't help you. Or be purposely trying to recreate an affected environment for testing/research, in which case it's on you. You're not wrong that we should keep our shields up - but "update sometime in the last 18 months" perhaps isn't such a revelation. One thing does come to mind though - I do wonder if there's a way to strongarm apt's dependencies mechanism into having openssh-server conflict with affected libxz versions, so that if you did apt update && apt install openssh-server in an affected image, it'd bring a fixed libxz along for the ride. (and the images don't carry apt manifests, so apt update is required and you would have today's package list.) You could still pin an affected version, so there'd still be enough rope to allow you to recreate a research environment.

▲

lmm 3 days ago | parent | prev [-]

> The XZ backdoor never made it to Debian stable. It is "still lurking in docker images" because Debian publishes unstable testing images, under a tag that is segregated from the stable release tags. You can find vulnerable containers for literally any vulnerability you can imagine by searching for the exact snapshot where things went wrong.

To a first approximation nothing ever makes it into Debian stable. Anyone working in an actively developed ecosystem uses the thing they pretend is an "experimental testing version". It's a marketing startegy similar to how everything from Google used to be marked as "beta".

▲

djkoolaide 3 days ago | parent [-]

Given my understanding of Debian, I don't believe this can be attributed to a "marketing strategy."

	▲	lmm 3 days ago \| parent [-]
		It probably evolved as such rather than being deliberately planned, but the end result is the same.