And sure, you definitely lose some niceties of Debian when you run it under Docker. You also lose some niceties of Docker when you don't.
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.
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.
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".
_Docker_ is a security hazard, and anything it touches is toxic.
Every single package, every single dependency, that has an actively exploited security flaw is being exploited in the Docker images you're using, unless you built them yourself, with brand new binaries. Do not trust anyone except official distro packages (unless you're on Ubuntu, then don't trust them either).
And if you're going to do that... just go to _actual_ orchestration. And if you're not going to do that, because orchestration is too big for your use case, then just roll normal actual long lived VMs the way we've done it for the past 15 years.
This is easy to say if your wallet exploded because it had too much money in it, and if you don't care about the speed of operations.
Just today I'm investigating hosting options for migrating a legacy web farm with about 200 distinct apps to the cloud.
If I put everything into one VM image, then patching/upgrades and any system-wide setting changes become terrifying. The VM image build itself takes hours because this is 40 GB of apps, dependencies, frameworks, etc... There is just no way to "iterate fast" on a build script like that. Packer doesn't help.
Not to mention that giant VM images are incompatible with per-app DevOps deployment automation. How does developer 'A' roll back their app in a hurry while developer 'B' is busy rolling theirs out?
Okay, sure, let's split this into an image-per-app and a VM scale set per app. No more conflicts, each developer gets their own pipeline and image!
But now the minimum cost of an app is 4x VMs because you need 2x in prod, 1x each in test and development (or whatever). I have 200 apps, so... 800 VMs. With some apps needing a bit of scale-out, let's round this up to 1,000 VMs. In public clouds you can't really go below $50/VM/mo so that's an eye-watering $50,000 per month to replace half a dozen VMs that were "too cheap to meter" on VMware!
Wouldn't it be nicer if we could "somehow" run nested VMs with a shared base VM disk image that was thin-cloned so that only the app-specific differences need to be kept? Better yet, script the builds somehow to utilise VM snapshots so that developers can iterate fast on app-specific build steps without having to wait 30 minutes for the base platform build steps each time they change something.
Uh-oh, we've reinvented Docker!
LeoPanthera•1h ago
https://www.nongnu.org/lzip/xz_inadequate.html
Analemma_•1h ago
lifthrasiir•1h ago