5 ms·

OK, honest question: why have the "The image you are pulling has been verified" message without also printing a disclaimer on `docker pull`? Secondly, It seems

OK, honest question: why have the "The image you are pulling has been verified" message without also printing a disclaimer on `docker pull`? Secondly, It seems that the author did not follow the stated docker procedure for security vulnerabilities (https://www.docker.com/resources/security/ 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.

gtirloni 12y ago
https://securityblog.redhat.com/2014/12/18/before-you-initiate-a-docker-pull/ https://securityblog.redhat.com/2014/12/18/before-you-initia... I think RH has also posted this just for the attention.
- ewindisch 12y ago
  I really advise caution with using 'docker load'. It's more susceptible to malicious input than 'docker pull' is. That said, it has a stronger trust story. Lets not confuse the two. If you know without a doubt that your image and all of its layers are safe, then you can use GPG to do image signing and verifications, then load the image into docker. 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 load
  - heavenlyhash 12y ago
    > It's more susceptible to malicious input than 'docker pull' is. That said, it has a stronger trust story. What 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.
    - ewindisch 12y ago
      It's mostly in how Docker perform the 'docker load' and 'docker pull' that results in a different security story, not so much how it ultimately extracts the files and applies them to the filesystem. 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.
  - wayoverthere 12y ago
    Running something inside a container does very little to actually secure it. If someone can execute arbitrary code inside a container, they can use a kernel exploit to jump outside of the container. It's important to always keep in mind that containers provide resource isolation, not a security boundary.
    - ewindisch 12y ago
      Running in a container restricts what processes may do in userspace. It's possible to take away CAP_SETUID, so that even if a process could execute arbitrary code, it could not leverage a setuid binary. There are a whole set of capabilities that admins may take away from their processes that are possible with a container. Some of these, yes, actually could protect against certain kernel exploits. 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.
23david 12y ago
The author is a developer and professional security researcher. He responds to the security disclosure issue on the github issue page: > @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. Source: https://github.com/docker/docker/issues/9719#issuecomment-67983737 https://github.com/docker/docker/issues/9719#issuecomment-67... Some good reading by Bruce Schneier re:full disclosure vs responsible disclosure: https://www.schneier.com/essays/archives/2007/01/schneier_full_disclo.html 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.

gtirloni 12y ago

https://securityblog.redhat.com/2014/12/18/before-you-initiate-a-docker-pull/ https://securityblog.redhat.com/2014/12/18/before-you-initia... I think RH has also posted this just for the attention.

ewindisch 12y ago
I really advise caution with using 'docker load'. It's more susceptible to malicious input than 'docker pull' is. That said, it has a stronger trust story. Lets not confuse the two. If you know without a doubt that your image and all of its layers are safe, then you can use GPG to do image signing and verifications, then load the image into docker. 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 load
- heavenlyhash 12y ago
  > It's more susceptible to malicious input than 'docker pull' is. That said, it has a stronger trust story. What 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.
  - ewindisch 12y ago
    It's mostly in how Docker perform the 'docker load' and 'docker pull' that results in a different security story, not so much how it ultimately extracts the files and applies them to the filesystem. 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.
- wayoverthere 12y ago
  Running something inside a container does very little to actually secure it. If someone can execute arbitrary code inside a container, they can use a kernel exploit to jump outside of the container. It's important to always keep in mind that containers provide resource isolation, not a security boundary.
  - ewindisch 12y ago
    Running in a container restricts what processes may do in userspace. It's possible to take away CAP_SETUID, so that even if a process could execute arbitrary code, it could not leverage a setuid binary. There are a whole set of capabilities that admins may take away from their processes that are possible with a container. Some of these, yes, actually could protect against certain kernel exploits. 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.

23david 12y ago

The author is a developer and professional security researcher. He responds to the security disclosure issue on the github issue page: > @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. Source: https://github.com/docker/docker/issues/9719#issuecomment-67983737 https://github.com/docker/docker/issues/9719#issuecomment-67... Some good reading by Bruce Schneier re:full disclosure vs responsible disclosure: https://www.schneier.com/essays/archives/2007/01/schneier_full_disclo.html 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.