Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Wednesday May 22 2019, @05:49PM   Printer-friendly
from the never-trust-someone-else dept.

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


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by ikanreed on Wednesday May 22 2019, @06:47PM (2 children)

    by ikanreed (3164) Subscriber Badge on Wednesday May 22 2019, @06:47PM (#846352) Journal

    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

    FROM {DANGEROUS_IMAGE}
    ARG SECURE_PASSWORD
    RUN echo "root:$SECURE_PASSWORD"|chpasswd

    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

    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 4, Interesting) by epitaxial on Wednesday May 22 2019, @08:00PM (1 child)

    by epitaxial (3165) on Wednesday May 22 2019, @08:00PM (#846364)

    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

      by ikanreed (3164) Subscriber Badge on Wednesday May 22 2019, @08:36PM (#846375) Journal

      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.