Live data from Hacker News

Analysis on Docker Hub malicious images: Attacks through public container images

sysdig.com

11–20 of 25 posts

Re: Analysis on Docker Hub malicious images: Attacks through public container images

#11

Earlier quoted context omitted.

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. 1. https://github.com/ossillate-inc/packj

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.

Re: Analysis on Docker Hub malicious images: Attacks through public container images

#12
post #6

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

Re: Analysis on Docker Hub malicious images: Attacks through public container images

#13

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 clo…

I can only assume these links are shared with malicious intent rather than found via docker search.

Re: Analysis on Docker Hub malicious images: Attacks through public container images

#14
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).

Re: Analysis on Docker Hub malicious images: Attacks through public container images

#15
post #3

With Docker, how well is the host protected from malicious images?

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

Re: Analysis on Docker Hub malicious images: Attacks through public container images

#16

Earlier quoted context omitted.

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

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…

> 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.

Re: Analysis on Docker Hub malicious images: Attacks through public container images

#18
post #6

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 convi…

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.

Re: Analysis on Docker Hub malicious images: Attacks through public container images

#19
post #14

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).

Redhat has moved all their stuff to quay.io.

Re: Analysis on Docker Hub malicious images: Attacks through public container images

#20
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).

* chroot * cgroups * PrivateNetwork * PrivateTmp * isolated devices * IPAddressAllow * SocketBindAllow * ReadOnlyPaths

https://docs.arbitrary.ch/security/systemd.html

Post reply on HN