[HN Gopher] Analysis on Docker Hub malicious images: Attacks thr...
___________________________________________________________________
Analysis on Docker Hub malicious images: Attacks through public
container images
Author : e-Minguez
Score : 54 points
Date : 2022-11-23 17:01 UTC (6 hours ago)
(HTM) web link (sysdig.com)
(TXT) w3m dump (sysdig.com)
| coffeeblack wrote:
| 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.
| naikrovek wrote:
| 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.
| ashishbijlani wrote:
| 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.
|
| 1. https://github.com/ossillate-inc/packj
| coffeeblack wrote:
| Don't know why you are downvoted.
|
| 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.
| naikrovek wrote:
| > 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.
| Yeroc wrote:
| 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).
| kjok wrote:
| 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.
| zdgmxdgm wrote:
| 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
| Doubleslash wrote:
| 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.
| emmelaich wrote:
| I can only assume these links are shared with malicious intent
| rather than found via docker search.
| TekMol wrote:
| With Docker, how well is the host protected from malicious
| images?
| dijit wrote:
| 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;
|
| [0]: https://docs.docker.com/engine/security/
|
| [1]: https://man7.org/linux/man-pages/man7/capabilities.7.html
| maldev wrote:
| 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.
| naikrovek wrote:
| this is all trending to a point where the number available
| libraries for an ecosystem will be seen as a liability rather
| than an asset.
| hermanb wrote:
| 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!
___________________________________________________________________
(page generated 2022-11-23 23:01 UTC)