[Analemma_]

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]

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]

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.