5 ms·

I wish the author had not omitted this crucial paragraph in the announcement he quotes: Note that this feature is still work in progress: for now, if a

by shykes 12y ago

I wish the author had not omitted this crucial paragraph in the announcement he quotes: Note that this feature is still work in progress: for now, if an official image is corrupted or tampered with, Docker will issue a warning but will not prevent it from running. And non-official images are not verified either. This will change in future versions as we harden the code and iron out the inevitable usability quirks. Until then, please don’t rely on this feature for serious security, just yet. So, we've made it pretty clear from the start that we're working on ways to make image distribution more secure, but are not claiming that it's more secure yet.

Alupis 12y ago
> So, we've made it pretty clear from the start that we're working on ways to make image distribution more secure, but are not claiming that it's more secure yet That very clearly makes Docker not secure from it's inception through today currently. That was/is the point of the article. > but are not claiming that it's more secure yet. What does "more secure" mean... it's either not secure or is secure. > This pipeline is performant but completely insecure. Untrusted input should not be processed before verifying its signature. Unfortunately Docker processes images three times before checksum verification is supposed to occur. > However, despite Docker’s claims, image checksums are never actually checked. Things like this are by design and at the core of how Docker does what it does. Docker clearly was not built with security considerations in mind. > Docker exacerbates this situation by running xz as root. This means that if there is a single vulnerability in xz, a call to docker pull could result in the complete compromise of your entire system. The security implications go on and on.
- mattmcknight 12y ago
  It doesn't make Docker "not secure", it means that you need to verify image files in the way you verify other files you download. These changes are irrelevant to the security of Docker itself, for the way I use it with my own images. "it's either not secure or is secure." Security is always a matter of degree.
  - Alupis 12y ago
    > it means that you need to verify image files in the way you verify other files you download That is difficult to script automation that handles all cases. They have mechanisms built in that claim they provide the security you would expect, except that this article exposes their claims are absurdly false and actually dangerous because most users are not going to take the time to verify what the code is actually doing -- ie. they will just trust Docker's claim and move forward, potentially blindly exposing themselves. > Security is always a matter of degree. I agree, except in this case Docker has totally cast most considerations of security out the window. Simple "best practices" like verify user/untrusted input before you begin to work with it are completely ignored as evidenced in this article. > Docker users should be aware that the code responsible for downloading images is shockingly insecure. The issue is Docker sweeps this under the rug and continues to claim their platform is secure. Users trust this, and leave themselves exposed. > It doesn't make Docker "not secure" It sure seems to indicate that Docker is certainly not secure.
- jaegerpicker 12y ago
  More secure means exactly what he says. Nothing is ever secure unless it's unplugged from the network. Security is a series of doors between your data and the attackers, making something more secure is simply adding more doors in front of it.
  - Alupis 12y ago
    > I assumed this referenced Docker’s heavily promoted image signing system and didn’t investigate further at the time. Later, while researching the cryptographic digest system that Docker tries to secure images with, I had the opportunity to explore further. What I found was a total systemic failure of all logic related to image security. The issue is Docker has never taken security seriously. From inception up to today. Security is an afterthought, very clearly evidenced by shykes comments above, and by the code being committed. Security for such a core piece of infrastructure, something Docker Inc hopes to thrust into all servers and devices someday, should rightfully be the first and foremost thoughts and part of the initial design of new features. Instead things are designed and developed, and security slips to the side. It takes articles like this to actually motivate Docker to do anything about it.
micah_chatt 12y ago
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.
Titanous 12y ago
Author here. > I wish the author had not omitted this crucial paragraph in the announcement he quotes: I did not quote this announcement, only linked to it. If this is intended to be prototype code, it should not be enabled by default, and certainly shouldn't be printing inaccurate messages to users in a 1.0 product. Also, the referenced warning goes to the daemon log, and doesn't appear to ever be triggered.
tuffle 12y ago
> but are not claiming that it's more secure yet That's a bit disingenous. The CLI clearly makes a security claim here, and you know very well that users will take it as one. I'm all for "working on ways to make image distribution more secure", but making security claims in the CLI when said security does not exist yet is -- assuming good faith -- a security bug in the user interface that should be fixed.
- shykes 12y ago
  I agree. The message should be more clear.
  - tedivm 12y ago
    Your two messages contradict each other- >So, we've made it pretty clear from the start >I agree. The message should be more clear. It seems like a bit of backpedalling here. Rather than try to blame the author for not understanding or quoting the announcement that most people wouldn't have read anyways I think you should just commit to fixing the underlying problem (first the message that's passed, then the actual feature itself) and thank the author for drawing attention to it and educating your users on the security issue at hand.
    - kstenerud 12y ago
      The first quote is in reference to the announcement. The second quote refers to the CLI messaging. Shykes is acknowledging the problem.
  - tuffle 12y ago
    It's good to hear that it will be fixed, but it's also troubling that a front-facing security issue took a #1 HN post, followed by debate in the comments before Docker recognized it.
    - shykes 12y ago
      All the issues in this post are already known and being actively discussed on the mailing lists and repo (including with the blog post author). However nobody so far had noted that the "image verified" message is misleading and should be clarified. I'm simply acknowledging that we should fix that, too.
jsmthrowaway 12y ago
I wish you'd take things like this seriously when they become public and not spend your time telling the world how everyone is wrong about Docker. The author spent a lot of time disassembling this issue and he doesn't even work for you; rather that interpret that as trying to make Docker better, which it is, you're right back on HN playing the "nobody understands what we say and everybody bullies us" attitude that Rocket really brought out of you. I wish you wouldn't do that. We can't all get what we wish for, apparently. The difference between your wish and my own is that the less I get mine, the more you alienate the people in this community. It's your prerogative not to care about that, but how you act on HN has really made clear to me that Docker is riding on simply being first, just as MySpace did.
- shykes 12y ago
  We do take security reports very seriously, when they were brought to the project repo: https://github.com/docker/docker/issues/9719 https://github.com/docker/docker/issues/9719 If you are looking to gauge our reaction to legitimate criticism and bug reports, you should follow the github repo and mailing lists, not hacker news.
  - jsmthrowaway 12y ago
    I'm not talking about Docker. I'm talking about you. Your first inclination is how people are wrong and only you are right, in every case. I don't understand your need to make everyone who criticizes Docker feel wrong, or like they missed something. Your thread here about Rocket was extremely alarming and directly motivated me to plan for a future without Docker. Best way forward here would have been "hey, thanks for looking into this, we know it's an issue." All of which you said later after making sure the author knew he missed something, which no normal user is going to look for anyway. The real bummer is you remind me of the CEO of Linode, whose company will fail for similar reasons. He is equally infallible and ignores criticism.
    - nknighthb 12y ago
      > you remind me of the CEO of Linode Hmm... You've just increased my respect for Solomon. > He is equally infallible and ignores criticism. As a long-time Linode customer, I know this to be absolutely false. Was it your intent to so thoroughly discredit yourself?
ossreality 12y ago
Then this is even more dumb than imaginable before. You shipped a broken feature, with an inaccurate message that gives a false sense of security and didn't bother putting it behind a flag, at the very least?
gitdude 12y ago
Professional Advice for shykes: Do some background research + internal prep before answering/commenting here on HN. You represent the Docker brand and over time such hastiness will erode Docker's credibility. Best to be silent than defend every incredulous comment about Docker on HN.

by shykes 12y ago

Alupis 12y ago

> So, we've made it pretty clear from the start that we're working on ways to make image distribution more secure, but are not claiming that it's more secure yet That very clearly makes Docker not secure from it's inception through today currently. That was/is the point of the article. > but are not claiming that it's more secure yet. What does "more secure" mean... it's either not secure or is secure. > This pipeline is performant but completely insecure. Untrusted input should not be processed before verifying its signature. Unfortunately Docker processes images three times before checksum verification is supposed to occur. > However, despite Docker’s claims, image checksums are never actually checked. Things like this are by design and at the core of how Docker does what it does. Docker clearly was not built with security considerations in mind. > Docker exacerbates this situation by running xz as root. This means that if there is a single vulnerability in xz, a call to docker pull could result in the complete compromise of your entire system. The security implications go on and on.

mattmcknight 12y ago
It doesn't make Docker "not secure", it means that you need to verify image files in the way you verify other files you download. These changes are irrelevant to the security of Docker itself, for the way I use it with my own images. "it's either not secure or is secure." Security is always a matter of degree.
- Alupis 12y ago
  > it means that you need to verify image files in the way you verify other files you download That is difficult to script automation that handles all cases. They have mechanisms built in that claim they provide the security you would expect, except that this article exposes their claims are absurdly false and actually dangerous because most users are not going to take the time to verify what the code is actually doing -- ie. they will just trust Docker's claim and move forward, potentially blindly exposing themselves. > Security is always a matter of degree. I agree, except in this case Docker has totally cast most considerations of security out the window. Simple "best practices" like verify user/untrusted input before you begin to work with it are completely ignored as evidenced in this article. > Docker users should be aware that the code responsible for downloading images is shockingly insecure. The issue is Docker sweeps this under the rug and continues to claim their platform is secure. Users trust this, and leave themselves exposed. > It doesn't make Docker "not secure" It sure seems to indicate that Docker is certainly not secure.
jaegerpicker 12y ago
More secure means exactly what he says. Nothing is ever secure unless it's unplugged from the network. Security is a series of doors between your data and the attackers, making something more secure is simply adding more doors in front of it.
- Alupis 12y ago
  > I assumed this referenced Docker’s heavily promoted image signing system and didn’t investigate further at the time. Later, while researching the cryptographic digest system that Docker tries to secure images with, I had the opportunity to explore further. What I found was a total systemic failure of all logic related to image security. The issue is Docker has never taken security seriously. From inception up to today. Security is an afterthought, very clearly evidenced by shykes comments above, and by the code being committed. Security for such a core piece of infrastructure, something Docker Inc hopes to thrust into all servers and devices someday, should rightfully be the first and foremost thoughts and part of the initial design of new features. Instead things are designed and developed, and security slips to the side. It takes articles like this to actually motivate Docker to do anything about it.

micah_chatt 12y ago

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.

Titanous 12y ago

Author here. > I wish the author had not omitted this crucial paragraph in the announcement he quotes: I did not quote this announcement, only linked to it. If this is intended to be prototype code, it should not be enabled by default, and certainly shouldn't be printing inaccurate messages to users in a 1.0 product. Also, the referenced warning goes to the daemon log, and doesn't appear to ever be triggered.

tuffle 12y ago

> but are not claiming that it's more secure yet That's a bit disingenous. The CLI clearly makes a security claim here, and you know very well that users will take it as one. I'm all for "working on ways to make image distribution more secure", but making security claims in the CLI when said security does not exist yet is -- assuming good faith -- a security bug in the user interface that should be fixed.

shykes 12y ago
I agree. The message should be more clear.
- tedivm 12y ago
  Your two messages contradict each other- >So, we've made it pretty clear from the start >I agree. The message should be more clear. It seems like a bit of backpedalling here. Rather than try to blame the author for not understanding or quoting the announcement that most people wouldn't have read anyways I think you should just commit to fixing the underlying problem (first the message that's passed, then the actual feature itself) and thank the author for drawing attention to it and educating your users on the security issue at hand.
  - kstenerud 12y ago
    The first quote is in reference to the announcement. The second quote refers to the CLI messaging. Shykes is acknowledging the problem.
- tuffle 12y ago
  It's good to hear that it will be fixed, but it's also troubling that a front-facing security issue took a #1 HN post, followed by debate in the comments before Docker recognized it.
  - shykes 12y ago
    All the issues in this post are already known and being actively discussed on the mailing lists and repo (including with the blog post author). However nobody so far had noted that the "image verified" message is misleading and should be clarified. I'm simply acknowledging that we should fix that, too.

jsmthrowaway 12y ago

I wish you'd take things like this seriously when they become public and not spend your time telling the world how everyone is wrong about Docker. The author spent a lot of time disassembling this issue and he doesn't even work for you; rather that interpret that as trying to make Docker better, which it is, you're right back on HN playing the "nobody understands what we say and everybody bullies us" attitude that Rocket really brought out of you. I wish you wouldn't do that. We can't all get what we wish for, apparently. The difference between your wish and my own is that the less I get mine, the more you alienate the people in this community. It's your prerogative not to care about that, but how you act on HN has really made clear to me that Docker is riding on simply being first, just as MySpace did.

shykes 12y ago
We do take security reports very seriously, when they were brought to the project repo: https://github.com/docker/docker/issues/9719 https://github.com/docker/docker/issues/9719 If you are looking to gauge our reaction to legitimate criticism and bug reports, you should follow the github repo and mailing lists, not hacker news.
- jsmthrowaway 12y ago
  I'm not talking about Docker. I'm talking about you. Your first inclination is how people are wrong and only you are right, in every case. I don't understand your need to make everyone who criticizes Docker feel wrong, or like they missed something. Your thread here about Rocket was extremely alarming and directly motivated me to plan for a future without Docker. Best way forward here would have been "hey, thanks for looking into this, we know it's an issue." All of which you said later after making sure the author knew he missed something, which no normal user is going to look for anyway. The real bummer is you remind me of the CEO of Linode, whose company will fail for similar reasons. He is equally infallible and ignores criticism.
  - nknighthb 12y ago
    > you remind me of the CEO of Linode Hmm... You've just increased my respect for Solomon. > He is equally infallible and ignores criticism. As a long-time Linode customer, I know this to be absolutely false. Was it your intent to so thoroughly discredit yourself?

ossreality 12y ago

Then this is even more dumb than imaginable before. You shipped a broken feature, with an inaccurate message that gives a false sense of security and didn't bother putting it behind a flag, at the very least?

gitdude 12y ago

Professional Advice for shykes: Do some background research + internal prep before answering/commenting here on HN. You represent the Docker brand and over time such hastiness will erode Docker's credibility. Best to be silent than defend every incredulous comment about Docker on HN.