Comment by Jeslijar
4 months ago
I'll let docker's security team know that an insecure, obsolete docker image is being served and the maintainers have officially acknowledged they will no longer support it.
Best to get insecure and vulnerable software out of the hands of those who may not be familiar with this CVE or their change in policy that has not gotten a press release in any way.
You're letting docker's security team know that they're serving Ubuntu 14.10? https://hub.docker.com/layers/library/ubuntu/14.10/images/sh...
there is a major difference between having an old image available and having it tagged as latest with no updates beeing available on a channel that before that published all updates with nearly no time delay
Someone seem to already be at it on Discussions https://github.com/minio/minio/discussions/21655
So that's not the same thing. Docker "official images" are a category of curated docker images. Minio is not one of them. The official curated images are here: https://hub.docker.com/u/library
The minio image is basically a community one that anyone could have created, but still shows in overall docker hub. It's created by minio themselves. I'm kind of surprised they haven't removed it, but with over a billion downloads they are easily in the top ten of whatever category they fall under creating substantial free advertisement.
Did you read the discussion? The docker steward is proposing making a docker "official" minio image to replace the minio/minio image.
1 reply →
Oh that will be an interesting discussion to watch.
> Best to get insecure and vulnerable software out of the hands of those who may not be familiar with this CVE or their change in policy that has not gotten a press release in any way.
Why is that the best? MinIO is not the type of thing that people ought to be directly making available on the Internet anyway, so CVEs are mostly irrelevant unless you are an organization that has to keep on top of them, in which case you certainly have a process in place to do so already.
People straight pulling an image off Dockerhub (so not a particularly sophisticated use-case) to run seem like they'd be the least likely to be impacted by a CVE like this. The impact is apparently "[it] allows the attacker to access buckets and objects beyond their intended restrictions and modify, delete, or create objects outside their authorized scope". Are people pulling from Dockerhub even setting up anything but the absolute most basic (Allow All) ACL?
Zero trust is the way to assess threat. Not Internet access or not.
No, it is a defense strategy. For e.g. hobbyists, it's basically irrelevant, and having something on a private LAN is fine. There is almost no chance of an issue. Not everything in the world needs to be maximally secured, and the people who are using those IAM policies are probably not pulling a vanilla image off Dockerhub to run something as fundamental as their storage layer. They probably also have firewalls tightly locking down which machines are able to talk to MinIO on top of token auth.
The cargo-culting around security is so bizarre to me. In a context where e.g. your organization needs to pass audits, it's cheaper/easier to just update stuff and not attempt to analyze everything so you can check the box. For everyone else, most security advisories are just noise that usually aren't relevant to the actual way software is used. Notably, no one in these discussions is even bringing up what the vulnerability is.
1 reply →
Regrettably Docker has let me know they are uninterested in taking any action.
"Hello,
This does not qualify as an infringement to our Terms of Use policy. Deprecating such images and repo(s) is the responsibility of the owner and we recommend you reach out to them. Docker advises its users to opt into using images under our official programs and offerings such as Docker Official Images and Docker Hardened Images.
Thank you, Security@Docker"
In their ToU under section 6.6, they outline how they may scan images for vulnerabilities and request the owners of said packages fix it, or simply remove it from their site. They clearly do not do this though even when notified of the high criticality vulnerability.
Unfortunately I don't think they're going to get involved there. There are already multiple "official" images on Docker Hub that are unmaintained and have plenty of CVEs (e.g. Centos https://hub.docker.com/_/centos/tags)
I think the most they'd do is add the DEPRECATED note to the Docker hub page as they have done for things like Centos
Imagine the absolute chaos if docker would do that, pull vulnerable images offline. Not a single company would be able to build their software anymore.
Actually, Docker did something like that, where they limited the amount of docker images they would host for you for free to a reasonable number. The result was pretty similar to this current outcry: https://news.ycombinator.com/item?id=24143588
[dead]
...Or just spend 10 minutes and familiarise yourself with the basic docker build command? Its really dead simple.
Then you have to maintain a pipline and registry just to fix something that should be fixed upstream?
Again folks, you don´t "fix" anything by building a docker image. The fix is already in the source, you just need to run one command to build the image. The registry is something you should have in your infrastructure, if you are at least half-way seriously doing anything in the domain of containers and Kubernetes. But if you dont have one, it seems you are running things locally, for your toy project.Well then, just in that case just deploy from your local docker cache. All of this is actually merely a couple of commands in your simplified use-case.
The fix is upstream, they're giving away the patch for free.
Setting up a registry and a pipeline is annoying but it's hardly a life changing event. It's certainly easier than migrating to a competitor.