New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE global threat #763

Closed
dav-m85 opened this Issue May 27, 2015 · 9 comments

Comments

Projects
None yet
8 participants
@dav-m85

dav-m85 commented May 27, 2015

Just wanted to notify for the recent @banyanops study showing that >30% of the images built here have CVE threats.

Any idea how to address that ? IMHO, we shall provide at least information on which boxes are CVE-free and which are not.

@md5

This comment has been minimized.

Show comment
Hide comment
@md5

md5 May 27, 2015

Contributor

It looks like they're pulling all tags from the Docker Hub API (cf. https://github.com/banyanops/collector/blob/c790b784d2b9bb68aaeb39dde3b3268aabde6289/metadata.go#L407), so that "30%" needs to be taken with a grain of salt. Because they're counting all tags and not just the currently supported tags, they're counting things that have already been fixed in many cases. I haven't run their tool myself since I don't have enough time or disk space to download every tag of every official image, so I can't say for sure how many of these vulnerabilities apply to currently supported tags.

Now, just because a tag isn't currently supported as defined by the Official Images project doesn't mean that people aren't using it. However, since we don't have usage numbers for what percentage of deployed and running containers are based on vulnerable builds of official images, it's hard to say what the actual impact of that 30% number is.

One thing I've discussed with @eave is the idea that Docker Hub should support tagging image IDs with metadata about whether or not they are vulnerable to known exploits like CVEs or NVDs. The docker client could then be enhanced to warn users when they're installing a known-vulnerable image ID (or a derived image that includes known-vulnerable layers). There could even be a mode where the docker client errors out if the vulnerabilities were assigned a "high" risk category.

If there are specific vulnerabilities in the currently supported tags of the Official Images, those should of course be addressed. In my experience, I've seen any reported CVEs for the Official Images addressed quickly and transparently.

Contributor

md5 commented May 27, 2015

It looks like they're pulling all tags from the Docker Hub API (cf. https://github.com/banyanops/collector/blob/c790b784d2b9bb68aaeb39dde3b3268aabde6289/metadata.go#L407), so that "30%" needs to be taken with a grain of salt. Because they're counting all tags and not just the currently supported tags, they're counting things that have already been fixed in many cases. I haven't run their tool myself since I don't have enough time or disk space to download every tag of every official image, so I can't say for sure how many of these vulnerabilities apply to currently supported tags.

Now, just because a tag isn't currently supported as defined by the Official Images project doesn't mean that people aren't using it. However, since we don't have usage numbers for what percentage of deployed and running containers are based on vulnerable builds of official images, it's hard to say what the actual impact of that 30% number is.

One thing I've discussed with @eave is the idea that Docker Hub should support tagging image IDs with metadata about whether or not they are vulnerable to known exploits like CVEs or NVDs. The docker client could then be enhanced to warn users when they're installing a known-vulnerable image ID (or a derived image that includes known-vulnerable layers). There could even be a mode where the docker client errors out if the vulnerabilities were assigned a "high" risk category.

If there are specific vulnerabilities in the currently supported tags of the Official Images, those should of course be addressed. In my experience, I've seen any reported CVEs for the Official Images addressed quickly and transparently.

@md5

This comment has been minimized.

Show comment
Hide comment
@md5
Contributor

md5 commented May 27, 2015

@md5

This comment has been minimized.

Show comment
Hide comment
@md5

md5 May 27, 2015

Contributor

For that matter, being able to query the Docker Hub API for currently supported tags of an image instead of having to look at the text description on Docker Hub would be helpful too.

Contributor

md5 commented May 27, 2015

For that matter, being able to query the Docker Hub API for currently supported tags of an image instead of having to look at the text description on Docker Hub would be helpful too.

@ewindisch

This comment has been minimized.

Show comment
Hide comment
@ewindisch

ewindisch May 27, 2015

Contributor

Agreed with @md5 that many of the figures here are for all tags, of which most are unsupported. Some figures, but too few, are specific to the latest tag, of this I think we could extract more meaningful data. Better yet, is if they could build this analysis against all of the supported image tags.

I agree that tooling such as Docker Engine or registries could provide better warnings/information about image EOL. If we could tag an image as EOL or give it an expiry, this could trigger info/warning messages to end-users. That could potentially help the issue of insecure "general images" as noted in the article.

Finally, if base operating systems do not patch for CVEs, we only inherit this. In fact, I know we've had to push at times for upstream distributions to patch security vulnerabilities. I'm curious to know what the difference here is to the cloud images for the same operating systems, to their bootable ISOs, and other installation mediums? We should strive to be excellent regardless, but the comparison to these other images and analysis specific to supported tags would be far more interesting to me in terms of how we might improve the security of images for users.

Contributor

ewindisch commented May 27, 2015

Agreed with @md5 that many of the figures here are for all tags, of which most are unsupported. Some figures, but too few, are specific to the latest tag, of this I think we could extract more meaningful data. Better yet, is if they could build this analysis against all of the supported image tags.

I agree that tooling such as Docker Engine or registries could provide better warnings/information about image EOL. If we could tag an image as EOL or give it an expiry, this could trigger info/warning messages to end-users. That could potentially help the issue of insecure "general images" as noted in the article.

Finally, if base operating systems do not patch for CVEs, we only inherit this. In fact, I know we've had to push at times for upstream distributions to patch security vulnerabilities. I'm curious to know what the difference here is to the cloud images for the same operating systems, to their bootable ISOs, and other installation mediums? We should strive to be excellent regardless, but the comparison to these other images and analysis specific to supported tags would be far more interesting to me in terms of how we might improve the security of images for users.

@psftw

This comment has been minimized.

Show comment
Hide comment
@psftw

psftw May 27, 2015

Member

I played with the collector tool to see what it does. It runs scripts to gather information such as all versions of packages and a package dependency graph. This information comes from the OS CLI tooling mostly. I don't see where they are doing anything with the non-OS software in the images, but it looks like they have a way to extend the functionality of banyanops/collector with user-defined checks as well. This sounds similar in theory to some of the testing scripts in this repository, except those are actual functional tests. I presume the SaaS offering takes the OS package info and analyzes it to produce the results in their post, but that part is currently a black box as I don't have an account yet. I'm hoping to get an account with banyan to see more details and see what other value they offer.

I think we agree that the bigger picture of staying on top of this across all official images (and beyond) is not an easy problem, but one that many people rely on us to handle for them. It isn't clear to me how thorough the analysis really is -- matching distro package versions against CVEs is useful, but only part of the picture. Raw results on a per image basis would be more interesting to review. This post is a good reminder that we should continue thinking about these things and improve our strategy as we go. I'm well aware that there has already been a good deal of work in this area, but we haven't communicated much about it and our efforts are not perfect. There is no perfect solution, only continuous effort to stay on top of the problem with the best assurance we can provide. We are still dependent on a number of external entities.

Member

psftw commented May 27, 2015

I played with the collector tool to see what it does. It runs scripts to gather information such as all versions of packages and a package dependency graph. This information comes from the OS CLI tooling mostly. I don't see where they are doing anything with the non-OS software in the images, but it looks like they have a way to extend the functionality of banyanops/collector with user-defined checks as well. This sounds similar in theory to some of the testing scripts in this repository, except those are actual functional tests. I presume the SaaS offering takes the OS package info and analyzes it to produce the results in their post, but that part is currently a black box as I don't have an account yet. I'm hoping to get an account with banyan to see more details and see what other value they offer.

I think we agree that the bigger picture of staying on top of this across all official images (and beyond) is not an easy problem, but one that many people rely on us to handle for them. It isn't clear to me how thorough the analysis really is -- matching distro package versions against CVEs is useful, but only part of the picture. Raw results on a per image basis would be more interesting to review. This post is a good reminder that we should continue thinking about these things and improve our strategy as we go. I'm well aware that there has already been a good deal of work in this area, but we haven't communicated much about it and our efforts are not perfect. There is no perfect solution, only continuous effort to stay on top of the problem with the best assurance we can provide. We are still dependent on a number of external entities.

@jgummaraju

This comment has been minimized.

Show comment
Hide comment
@jgummaraju

jgummaraju May 27, 2015

Thanks for the comments!

We intentionally did not publicize which images have what vulnerabilities, etc. because we did not want to offend/blame any stake holders. Our focus was more to make people aware of the security vulnerabilities so that they take this into account in their container deployment strategy. That said, we'd love to work with the official repositories team on some of this stuff. What would be a good way to move forward? @md5 @ewindisch @psftw

Good point about generating results just for supported tags -- we should be able to do that pretty quickly!

Cheers,
Jayanth

jgummaraju commented May 27, 2015

Thanks for the comments!

We intentionally did not publicize which images have what vulnerabilities, etc. because we did not want to offend/blame any stake holders. Our focus was more to make people aware of the security vulnerabilities so that they take this into account in their container deployment strategy. That said, we'd love to work with the official repositories team on some of this stuff. What would be a good way to move forward? @md5 @ewindisch @psftw

Good point about generating results just for supported tags -- we should be able to do that pretty quickly!

Cheers,
Jayanth

@eave

This comment has been minimized.

Show comment
Hide comment
@eave

eave May 27, 2015

We're speaking with Tarun on Friday—perhaps you could follow up with him and join?

Best,
Mario

eave commented May 27, 2015

We're speaking with Tarun on Friday—perhaps you could follow up with him and join?

Best,
Mario

@jgummaraju

This comment has been minimized.

Show comment
Hide comment
@jgummaraju

jgummaraju May 27, 2015

Ah yes, sounds great! I'm on that invite already...Just wasn't sure if the agenda was different for that call.

Looking forward to it!

Thanks,
Jayanth

jgummaraju commented May 27, 2015

Ah yes, sounds great! I'm on that invite already...Just wasn't sure if the agenda was different for that call.

Looking forward to it!

Thanks,
Jayanth

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon May 27, 2015

Member

Here's a good start:

$ bashbrew/bashbrew.sh list --all

The follow-up:

$ bashbrew/bashbrew.sh list --all --uniq
Member

tianon commented May 27, 2015

Here's a good start:

$ bashbrew/bashbrew.sh list --all

The follow-up:

$ bashbrew/bashbrew.sh list --all --uniq

@yosifkit yosifkit closed this Sep 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment