19.4 percent of the Docker store's top 1000 containers have no root password, potentially exposing users' systems to attacks under certain conditions.
Last week, a similar flaw was found impacting the official Alpine Linux Docker image, when Talos researchers discovered that all images since v3.3 were shipping with a root account with a null password. The vulnerability meant attackers who infiltrated systems via another entry point, or users with shell (remote) access, could elevate their privileges to root within the container.
Over the weekend, security expert Jerry Gamblin built a script that checked the top 1000 docker containers from the Docker store to determine if they were impacted by the same misconfiguration.
After tweaking the script to correct for duplicates, Gamblin found that 194 of the 1000 containers he analysed had blank passwords, including images from the UK government, HashiCorp, Microsoft, Monsanto and Mesosphere.
Sources:
[Editors Comment: The submitter is employed by the first source. Alternative sources have been found for this story to verify its content.]
(Score: 3, Informative) by ikanreed on Wednesday May 22 2019, @06:47PM (2 children)
Daemon runs as root, any docker run command can take arbitrary volumes, run commands often controlled by swarm config files in unprotected spaces, container buffer overruns are still real physical threads on the host system, the fact that group docker is the same thing as group sudoer.
Only a little of that affects the use cases for docker I have where I work. This one not at all.
The solutions of this particular problem for a sensible developer are pretty easy though
Then you can set it to whatever you want at build time, without having the password kept in an insecure place like a git repo
(Score: 4, Interesting) by epitaxial on Wednesday May 22 2019, @08:00PM (1 child)
Docker is just a product of a larger problem. Code is so fragmented and broken that only the author can compile it. So instead of cleaning up the problems they just make a container.
(Score: 4, Informative) by ikanreed on Wednesday May 22 2019, @08:36PM
Yeah, it does seem to be abused that way.
My use case for it is a little more particular. We want to be able to certify to a third party that we can re-run exactly the same code in exactly the same way 15 years after it was run the first time, bugs and all. Sticking all the code and all the system dependencies into a sealed image we can file away forever is a nice choice.
There is another case for it though, where it's not just a lampshade on laziness and bad docs. Dynamic scaling. To be able to deploy particular applications to more nodes as demand increases is kind of a hard problem without docker. Doing a flat clone brings environment stuff that gets in the way. Rebuilding Just In Time style doesn't scale rapidly enough for anything realtime. It fits a neat niche, without needing a homeroll solution.