I understand the position that these old containers are not and cannot be supported, but I disagree with the argument that this is a vulnerability in unmaintained software and therefore should not be fixed. It’s malware. One should not knowingly host malware even if the activation of that malware isn’t likely.
this post was submitted on 17 Aug 2025
160 points (97.1% liked)
Linux
9127 readers
375 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
from March 11, 2024, when the backdoor was in play.
Ah yes, I remember the days when the backdoor was still in play.
I have a particular feeling which I want ask you all.
In the last few years, I have seen that some new cyber security firm will come up with a new 'novel' security vulnerability, and media will give those 'vulenrability' huge coverage, but in the end in reality that vulenrability is just of academic interest, and without any real life implications?
There was a 'logo fail' vulnerability, then GitHub 'leaking' credentials (it was bad narrative built around a GitHub feature), and so many more.
All I see is fear mongering with sensationalised media coverage. Am I the only one feeling this way?
“The backdoor targeted SSH servers by hooking into OpenSSH's cryptographic functions through the liblzma.so library.”
Not exactly academic in this case.
Who's running OpenSSH servers in their old Debian containers anyways?
You're getting down voted and I have no idea why.
Why would anyone run an ssh server in an app container? You'd ssh to the host and attach to the shell of the container if you needed shell access for some reason. I've only ever needed shell access to debug something or test a file mount.
In fact, minimal or "distroless" containers don't even have a shell.
I honestly can't think of any good reason to run an ssh server in a container.
What if you didn't have permission to access the host, only the container?
I don't understand this scenario. I can't fathom why this would ever be the case. It sounds like either a very poor use of containers, or a very niche situation that I just don't understand.
That'd be an unusual setup. If you have users deploying containers on your host -- that you trust enough to run whatever containers, but don't want to give them ssh to the host -- you'd usually have some kind of frontend such as Portioner, where you can have container exec and such.
Containerization is not virtualization. It's very possible to break out of containers, especially if configured badly, or if there are any found exploits in the container engine or even the kernel. Containers are "good enough" for the majority of projects, but it has never been designed to be a truly hardened sandbox.
Basically, if you're running an OpenSSH server inside a container, it's likely that you've gotten the wrong ideas about securing your environment, and thus some old libraries in an old Debian image is the least of your worries.
Sounds like a VPS. I doubt docker is sandboxed securely enough you'd want to use it for such an operation. VPS to my knowledge is done by virtual machine.
> I honestly can’t think of any good reason to run an ssh server in a container.
An isolated virtual machine for untrusted users?
That's not the kind of container that's being discussed. These are app containers that are built to just run one app.
Part of it is because journalism is dead and media generally do not understand cyber security.
Second, if it’s a really good bug, you don’t always want to publish it for free. You’re more likely to sell that information. I think those kinds of bugs tend to get exploited and patched under wraps.
A US family moving into their new tent after a flood destroyed their old home. Nothing is free.