Secondly, It seems that the author did not follow the stated docker procedure for security vulnerabilities (https://www.docker.com/resources/security/). In my view this taints the author's position of revealing a vulnerability to the community and reduces it to mere attention-getting.
I think RH has also posted this just for the attention.
That assumes that what you're signing and verifying is safe, i.e. non-malicious. Again, 'docker load' is less protected against malicious inputs, so under no circumstance is it safer to load arbitrary, untrusted content through this mechanism.
Finally, an interesting middle-ground is to containerize the 'docker pull', then use Docker itself to generate sanitized input to 'docker load'. It's not perfect, there are still ways to attack it, but I did put together a PoC of this:
$ docker run ewindisch/docker-pull ubuntu | docker loadWhat does that mean?
Let's look at how 'docker pull' and 'docker load' compare:
- They're both loading an image into docker.
- They're both NOT checking any signatures in any meaningful way.
- All that's different about `docker pull` is that it's fetching directly from the network.
How could 'docker load' possibly be more susceptible to malicious input?
Clearly, there is never any circumstance in which it is safe to load arbitrary, untrusted content through docker. I fail to see how loading untrusted content from the network could be safer than loading untrusted content from disk.
When you use 'docker pull', you're explicitly loading a specific tag and the layers associated with it.
Docker 'load' doesn't load an image and a tag as specified by the user, it loads an arbitrary number of images and tags as specified in the provided archive.
For one example of an actual vulnerability, up until Docker 1.3.3, it was possible for a 'docker load' to execute path traversal attacks based on malicious image IDs. This was largely mitigated by the 'docker pull' code and url semantics. There was still some risk from malicious registries, but again, mitigated by having a trusted registry behind TLS.
However, no, containers do not entirely protect against kernel exploits. Yet, is that what we're talking about there where the alternative is to simply execve(3) a binary, and possibly setuid to a non-root uid? Running processes with a restricted capabilities set and new namespaces is generally more secure than running them without these restricted capabilities without namespaces.
So yes, actually, containers do provide security. No, it's not absolute, but it's better than the alternative if the alternative is a naive 'execve' or one of its many frontends.
> @ewindisch:
> I also remind everyone that if they feel there may be possible attacks
> against the current format, not to publicly discuss this on GitHub.
> If you do feel this way, I'll happily entertain a private discussion.
> While I generally prefer and encourage transparency in open source
> projects, we should be careful to practice responsible disclosure.
Disclosing security vulnerabilities is a responsible thing to do.
As a security researcher, it is entirely my choice how/when/if I disclose
security issues. In this case, I'm not dropping any 0-days, just pointing out
fundamental flaws in the current system. Fixing these flaws should be an
open discussion, not a private one.
As far as "responsible disclosure" goes, it is only one vulnerability
disclosure approach (the alternative is not "irresponsible disclosure"),
and there is zero consensus about it.
Some good reading by Bruce Schneier re:full disclosure vs responsible disclosure: https://www.schneier.com/essays/archives/2007/01/schneier_fu...
If you want to really understand the security world, I definitely recommend attending Defcon in Las Vegas at least once to meet our Cyber brethren... :-)
Companies with the resources who publicly state that they care about security should be willing and excited to at least partially sponsor employees to go. Definitely worth every penny.