Critical Bug in Docker Engine Allowed Attackers to Bypass Authorization Plugins
64 points by jebby 11 months ago | 15 comments- erickj 11 months agoHmmm... It's as though running root privelege daemons with open sockets could go wrong. Who could have known.
https://developers.redhat.com/blog/2020/09/25/rootless-conta...
- broknbottle 11 months agoHmm it’s as though Linux is living in dark ages and having a root be a special user could result in something going wrong. Perhaps Lennart will come will return to Red Hat after his stint at Microsoft and introduce SecureTokens
- broknbottle 11 months ago
- compsciphd 11 months agoAre there really good use cases for dockerd being exposed to the network?
I would assume (many/most) users who run docker directly run it without api access on the network (i.e. on a single host).
Even those that do want network deployments of docker, probably run it through something like k8s where again kubernetes is handling the networking side, and each dockerd doesn't need to expose a network accessible api).
just wondering the use case for this.
- radus 11 months agoExample: you want to set your local docker context to the production environment, so that when you type `docker system prune --volumes` you delete your production data.
- rudasn 11 months agoRight? I always wondered who would use that feature and for what, now it all makes sense!
- awithrow 11 months agoHonestly this sounds like a massive outage waiting to happen
- hotsauceror 11 months agoThat’s Ops’s problem later tonight. You have to move fast and break things.
- hotsauceror 11 months ago
- rudasn 11 months ago
- chatmasta 11 months agoThe issues arise when “the network” means something different at deployment time. You might plan or expect “the network” to be shared only by local services. But then you add some management GUI that needs access to it. And then you add a sidecar to that. And before you know it, you’ve got a bunch of containers, all with their own attack surface, and all with access to the dockerd socket.
- claytonjy 11 months agoMy first thought was CI providers, where we often have to specify a "service" to allow `docker build`.
I don't know much about the internals there; would this bug allow me to do bad stuff on shared CI runners?
- hibbelig 11 months agoDocker desktop for Mac: dockerd runs in the VM and the client from the host system wants to connect. But of course we all hope that the network it is exposed to is still only on the Mac.
- m463 11 months agorelated, note that docker will money with the firewall and let itself through unexpectedly:
https://vpetersson.com/2014/11/03/the-dangers-of-ufw-docker....
- radus 11 months ago
- jroseattle 11 months ago> The vulnerability was addressed with the release of Docker Engine v18.09.1, but it was not included in subsequent major versions, causing a regression.
Without further information, this sounds like code introduced in a hotfix that wasn't merged back to feature branches.
Surely it's not that simple?
- mass_and_energy 11 months agoHow does this affect CaaS-based deployments like AKS, EKS, GKE and the like?
- stackskipton 11 months agoThey are not using Docker for container runtime. It was deprecated in Kubernetes 1.20 and removed in 1.24 with almost everyone switching to containerd. Currently supported Kubernetes versions are 1.28/1.29/1.30. 1.27 is available as LTS from a few providers.
EDIT: Coworker mentioned there is a cri that lets you to continue to use Docker Engine in Kubernetes but I've never run across it.
- Arnavion 11 months agoI doubt any of those use dockerd. They likely all use containerd directly.
- stackskipton 11 months ago
- 11 months ago