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.
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.
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.
Do you have any recommendations for pull-thru caching? I’m currently going through this issue as we speak and am very interested in having this work for our usecase.
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.
these all inherently trust the code submitted to them. scanning tools cost a lot of money, but even the best scanning tools can't begin to detect malicious activity, because malicious activity often looks exactly like legitimate activity.
While no automated tool can accurately catch all malware, I'm building Packj [1] to provide objective security insights into software artifacts. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out spawning of shell, use of SSH keys, mismatch of GitHub code vs packaged code (provenance), etc.
It’s a noble mission, but eventually a pointless one, I believe. It looks more and more like the entire strategy of having a bazillion mini repos all importing each other is doomed to fail.
But hey, maybe I’m wrong and all those automated auditing tools actually manage to keep dependencies sufficiently safe.
That would be the best outcome, but I am increasingly pessimistic. There is just too much to gain.
> It looks more and more like the entire strategy of having a bazillion mini repos all importing each other is doomed to fail.
I think it's already a failure for some people, because of problems like the one this thread is about.
I and a few others I know advocate against using libraries if at all possible, and always when the library is small with few methods, both so that you can know what you're running (always a good idea, of course) and so you can gain the experience of solving that problem. I believe that writing different parts of software will make you better at writing all software; writing ORMs all day won't help you get better at reading binary files, for example.
People always look at me very strangely when I say "avoid libraries when possible" but I think the idea that libraries are an open doorway for malware is going to be more and more obvious as time goes on. Browser extensions are constantly sold to bad actors for large sums of money, because the amount of money offered can be life-changing for the extension author. It's going to happen more and more with libraries as well.
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?
Or why aren’t more people interested in this?
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.
what baffles me is that every time i see a mention of malicious images, the comments are always along the lines of "nobody would ever use these random images" and "isn't this why companies usually have private mirrors?".
then i go to work and i spend the majority of my week asking questions like "where is the dockerfile for this jimbob/diffusers image you're basing your work on?" or exhaust political capital on convincing leadership that it's worth our time to vendor all our dockerfiles from `scratch` up, and regularly rebuild them in ci vs just pulling them from dockerhub.
all the "if you use common sense you're fine" posts don't match my experiences in helping numerous companies un-fuck their container infrastructure
I agree. People tend to search for variations of "$application docker" to see if there's an existing image they can reuse. People also tend to associate search engine ranking with credibility (a big reason why ads disguised as results taking the top places is unethical, but I digress), which means that a threat actor could easily get people to use a malicious image if they write a blog post or guide and boost it with SEO.
Unless you have access to unambiguously official images, like from Red Hat, most images are "random". There are tons of popular non-official images maintained by random organizations or people (e.g., bitnami, LinuxServer) that you just have to trust.
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).
These kinds of repository are probably best used by drive-by malware.
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 heavy sigh 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).
It's controversial because there are definitely a contingent of people who really want to believe docker adds a realistic layer of security isolation.
But no credible security researcher, security engineer or even Docker the company itself has ever considered Docker the container runtime to be a security mechanism (well, outside of the fact it's leveraging kernel namespaces)[0].
There's also a lot of really bad security hygiene when it comes to running docker images even if they could be secure: Docker runs programs by default as root and this gives programs quite a lot of possibility to escape a container, many containers are used in CI (DinD) which exposes the host docker daemon, most containers are not run with `--cap-drop all` which drops capabilities from the kernel[1], I have never seen a container run with `--security-opt=no-new-privileges` which would prevent escalating privileges using `setuid` or `setgid` binaries (leading to the same issue as running everything as root), etc, etc, etc;
Thanks for pointing to these options; is there a list you can recommend of everything that should be done (hopefully updated regularly)? It is quite the arms race.
The host should be protected in regards to code execution (Assuming theirs no escape).
The big issues come in the fact that you may pass in proprietary/confidential files, for example Code, which is now at risk of being leaked and the company faces extortion. Or you have a network configuration where the malware can pivot onto another server and now your whole environment is exposed to risk.
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.
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.