The segmentation into attack vectors is interesting. But images from individuals on something like DockerHub have always been untrusted. I expected to read here about recent compromised official DockerHub library images.<p>I don't see how that threat is new or now more pressing than ever. How would you even count something like `docker pull vesnpsexga/joomla` as typosquatting vs. `docker pull joomla`? It's not even close.<p>Users should limit there container runtime/podman/docker access to docker.io/library or use a pull-thru caching feature of their own registry to bring in stuff from hand-selected places in public registries like docker.io or quay.io to environments behind the firewall.
Does every “registry” or “hub” have to repeat the same mistakes? It’s not like the same didn’t happened on pypi, npm, crates, and who knows how many others.
Honestly, this seems like little. We should be wary of the source we try to pull, but given how easy it is to upload something malicious you’d expect thousands of images of this kind. Maybe DockerHub is already detecting and deleting these packages?<p>Or why aren’t more people interested in this?<p>Not sure, but maybe injecting into commonly used libraries via subdependencies is seen as a more effective method, getting more focus. Would be interesting to have a broader analysis of malicious artifacts!
Given that these malicious images seem esoteric (only a few hundred downloads), is this even a threat? Most companies have private mirrors that protect against such attacks.
This sounds like much-ado about nothing. We probably need to be far more concerned about "Docker Official Image"s that have been deprecated and are no longer receiving updates such as the "official" /_centos images (including centos7 which in theory isn't EOL but RedHat apparently doesn't care).
A couple hundred downloads?<p>These kinds of repository are probably best used by drive-by malware.<p>I think this (and all) repository's download log should be made open, or at least made viewable prior to your downloading step as part of the trust profiling.
Don't use Docker. Use <i>heavy sigh</i> systemd security features. Yes, this is something that systemd actually does really well. And it keeps all your processes and files visible and inspectable to standard unix tools (ps, htop, ls, etc).<p>* chroot
* cgroups
* PrivateNetwork
* PrivateTmp
* isolated devices
* IPAddressAllow
* SocketBindAllow
* ReadOnlyPaths<p><a href="https://docs.arbitrary.ch/security/systemd.html" rel="nofollow">https://docs.arbitrary.ch/security/systemd.html</a>