17 Backdoored Images Downloaded 5 Million Times Removed From Docker Hub (bleepingcomputer.com) 36
An anonymous reader writes: "The Docker team has pulled 17 Docker container images that have been backdoored and used to install reverse shells and cryptocurrency miners on users' servers for the past year," reports Bleeping Computer. "The malicious Docker container images have been uploaded on Docker Hub, the official repository of ready-made Docker images that sysadmins can pull and use on their servers, work, or personal computers." The images, downloaded over 5 million times, helped crooks mine Monero worth over $90,000 at today's exchange rate. Docker Hub is now just the latest package repository to feature backdoored libraries, after npm and PyPl. Docker Hub is now facing criticism for taking months to intervene after user reports, and then going on stage at a developer conference and claiming they care about security.
Re: (Score:3)
Indeed, even Hitler agrees with that [youtu.be]
justification (Score:5, Insightful)
Re: (Score:3)
Yep. Devs and Systems Eng wanted the kubernetes clusters to have internet access in order to download containers. I refused and built containers and pushed them to our internal repo.
[John]
Re: (Score:2)
I have always been too picky to trust peoples images, if theres something I want to use I will build it myself and store it on my private docker repo.
There's a capability question with all of those approaches. I only started playing with docker for the first time 2 months ago, and boy was it complicated. There's a lot to take in when working with it. Personally I had enough problems figuring out how persistent storage worked and the idea of passing settings to the docker container. I would happily say building your own docker image is beyond a large portion of even linux users.
Damn it (Score:2)
I read that there are images, some backdoors, downloaded gorillion times... and I was ready with the lube next to me... ...but apparently, images can mean .iso files.
Damn it.
Re: (Score:2)
Oh whew. I thought it was back to the bad old days where poisoned pictures crashed decompressors in just the right way to take control.
Unbelievable (Score:4, Informative)
All 17 images were uploaded on the Docker Hub portal by the same person/group, using the pseudonym of "docker123321."
WHO THE FUCK pulls an image called docker123321/tomcat22 ?
Re: (Score:2)
Re: (Score:1)
Or 5 million CI servers.
Re: (Score:2)
Yes, especially CI servers that are using a regex to find the most recent version of software using numerical comparison.
So you are saying ... (Score:3)
So you are saying that when the image is run under Docker, it can write to the host filesystem, open ports, etc.. Isn't it sandboxed?
I am not sure how one can claim to care about security without a secure sandbox.
Re: (Score:2)
A sandbox does not prevent one to mine a crypto currency ...
Re: (Score:2)
Read my post again. Note carefully the part of the article that I quoted.
Re:So you are saying ... (Score:4, Informative)
That depends on the container, but yes. The spec of a container can include direct access to host resources, including directories, or not. Adding to the fun, if you grant a user sufficient access to docker to run their own images, you have effectively granted them root.
Re: (Score:2)
I am not sure how one can claim to care about security without a secure sandbox.
How are you posting this right now? Your browser is sandboxed but it has port 443 open? The idea behind any sandbox is to only open access to what you need for the core functionality and isolate everything else.
Now you've just convinced someone to download an image called docker123321, do you think it would be difficult to convince them to run the image using a command that allows access to parts of the file system / open ports?
Docker is well sandboxed, but gives the user enough rope with which to hang them
Re: (Score:2)
Well if nothing else, at least as of Meltdown the guest could dump the hosts memory, which should make it hell of a lot less difficult to gain access to the host (not necessarily from within the container)