This entirely misses the point of Docker.
It’s just pointing out the risk of letting someone you don’t know with no legal obligations setup your complete environment.
How likely
Probably as likely as someone cracking your really secure ssh password. Still, any sane expert will recommend disabling password auth.
I only pull containers based on some official project.
How do you know they weren’t compromised?
but I don’t see anything here about Docker itself being a problem
The problem is that rootless docker is a pain and no one does it. Privileged software sideloading other software is a huge risk.
That risk now became an incident. Even if you’re not affected, the risk still remains.
How do you know they weren’t compromised?
I don’t think that’s possible to know definitively, but I will say that this research doesn’t indicate that any images or repositories were compromised, only that a bunch of malware-ridden images were pushed to new repositories. In other words, it’s like they’re implying Google Drive is compromised because someone uploaded malware to their own account and are sending links to it. AFAIK, there wasn’t an attack on Docker as a platform or any existing repositories, these are just new repositories set up to host malware.
The proper mitigation here is to inform users how to find “official” images and repositories. Pulling a Docker image is like downloading any form of software, make sure you trust the source before pulling it down.
The problem is that rootless docker is a pain and no one does it
Nobody does it because it’s generally not necessary.
The reason to run system services as non-root is because there’s no sandbox to keep you safe. Docker provides that sandbox. Yeah, rootless containers are better security-wise since it provides another level of protection, but just using any sandbox follows the Pareto principle (80% benefit for 20% effort). Yeah, you probably should use rootless containers, but the focus should be on making sure the configuration for the container doesn’t expose more than necessary.
The following needs to happen for a user to be impacted:
- download untrusted docker image - similar to downloading random executables from the internet
- configure untrusted docker image with way more access than is necessary - as in, essentially eliminate the sandbox
- run the container on a system with valuable data on it w/o backups - production systems should separate data from applications (i.e. mount points, S3-like buckets, etc), and development systems should have backups
There’s no Docker vulnerability here, so the title is unnecessarily alarmist. Docker hub is still absolutely safe to use, just make sure you trust the repositories and images you use.
What you are saying is not new but you don’t seem to grasp the difference in risk when you run someone else’s configured environment on your system vs. manually setting them up yourself. You save a lot of time by using docker images but it comes with a price.
There’s no docker vulnerability
No need to. Like sudo doesn’t need a vulnerability when you let contributors of some repository use it on your box.
Things like snyk exist for a reason but it’s not mitigation, just monitoring.
You should stop telling people that using docker is no security problem because that’s wrong, as it adds attack surface to even the most secure projects. Sure, it saves time but things like OPs news will keep popping up in the future like it did in the past. It can’t be fixed other than just not using it in production. At least build your own containers.
Don’t forget various past issues:
- https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/
- https://osric.com/chris/accidental-developer/2018/12/using-docker-to-get-root-access/
- https://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/
- https://blog.alexellis.io/docker-is-deleting-open-source-images/
I said it’s not a Docker problem in the same way that installing a malware-laden executable isn’t an OS problem. Yes, you can install malware through Docker if you opt-in, the trick is to not opt-in. Check where they’re coming from, look at multiple examples online and see if they’re all using the same image, etc. Do your due diligence, especially if you’re not a developer and thus looking at the Dockerfiles is impractical.
But unless there’s an actual vulnerability in Docker (i.e. exploit in the daemon, credential breach of Docker hub, etc), the finger should be pointed elsewhere. Maybe that’s the kernel (i.e. breaking out of the sandbox), but it’s likely blog posts and users that are at fault.
I looked through those links, and here are my thoughts:
- Yes, Docker vulnerabilities are a problem, but an attacker would need to trigger the vulnerability and break out of the sandbox, so it’s not as serious imo; users should stay up to date though, especially if they’re using a popular base image
- This comes down to user configuration; if you confine a volume properly, it shouldn’t be an issue.
- This is really bad, and it’s heartening to see Docker take it seriously. A breach is by far my biggest concern when it comes to hosted services like this.
- I’ll need to find a follow-up to see how Docker handles account deletions, because if names can be reused, that’s ripe for exploits.
Yes, there are plenty of opportunities for exploits in the Docker ecosystem, but I think the risk is pretty low given Docker has it’s own sandbox, which adds a layer of complexity to exploits. The focus shouldn’t necessarily be on something Docker should be doing, but teaching users how to configure containers properly. That means:
- one process per container - nudges users to configure things properly, which reduces risk (limit access to data, executables, etc)
- rebuild frequently - using more general names (e.g. python:3.10) instead of specific names (python:3.10.3) means you’re more likely to get security updates when you rebuild; this also means scans targeting big repos are more effective since that’s just one org to contact
- do regular backups - ransomware attacks should be a complete non-issue, and other malware attacks should be reasonably easy to recover from
No platform is perfect, and practicing the above is probably easier than implementing non-root containers, and non-root itself isn’t a cure-all. Do the above first, and then consider non-root containers in production.
