Re: [openstack-dev] Would people see a value in the cve-check-tool?
Hi Adam, Thank you for your suggestion! I will send also this proposal to openstack-security@. I have previously attached the wrapper python class to the email, but it seems that it didn’t reach people. Let me try again (now in a form of an archive) and see if it goes through this time. Best Regards, Elena. From: Adam Heczko [mailto:ahec...@mirantis.com] Sent: Monday, August 3, 2015 3:18 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Heath, Constanza M; Ding, Jian-feng; Demeter, Michael; Bhandaru, Malini K Subject: Re: [openstack-dev] Would people see a value in the cve-check-tool? Hi Elena, the tool looks very interesting. Maybe try to spread out this proposal also through openstack-security@ ML. BTW, I can't find the wrapper mentioned - am I missing something? Regards, Adam On Mon, Aug 3, 2015 at 11:08 PM, Reshetova, Elena elena.reshet...@intel.com mailto:elena.reshet...@intel.com wrote: Hi, We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process? A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies. The tool is located here: https://github.com/ikeydoherty/cve-check-tool I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs). Best Regards, Elena. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Adam Heczko Security Engineer @ Mirantis Inc. wrapper.zipx Description: Binary data smime.p7s Description: S/MIME cryptographic signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Would people see a value in the cve-check-tool?
On 08/03/2015 04:08 PM, Reshetova, Elena wrote: Hi, We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process? A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies. The tool is located here: https://github.com/ikeydoherty/cve-check-tool I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints. txt and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs). Best Regards, Elena. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev As a packager I love this :D -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Would people see a value in the cve-check-tool?
Arguably also 3. lots of CVEs which aren't applicable for some reason, so we likely need a means to whitelist those and filter them from the report. cve-check-tool supports whitelisting and won't report the CVEs that have been marked as ignore. The temporal faux format that I am filling in the python wrapper has a place to put such CVEs. So, only thing that would be needed from your side is to define how/where you want to store list of CVEs to be ignored for each package and I can process them in the wrapper similarly. Best Regards, Elena. smime.p7s Description: S/MIME cryptographic signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Would people see a value in the cve-check-tool?
Hi Elena, This is interesting work, thanks for posting it (and for posting it here on openstack-dev, we are trying to wind down the security ML) though maybe use the [Security] tag in the subject line next time. I think this is a very interesting project, though it’s unclear to me who might be the targeted users for this? It seems like it would make the most sense for this to be in the gate. Now this could be the standard build gates (Jenkins etc) but I’m not sure how much sense that makes on its own, after all most production consumers (those who care about CVEs) of OpenStack are probably not consuming it vanilla from source but are more likely to be consuming it from a vendor who’s already packaged it up. In the latter case, I’m sure vendors would find this tool very useful, we do something similar at HP today but I’m sure a tool like this would add value and it’s probably something we could contribute to. As I write this I’ve realised that there would be an interesting possibility in the former case (putting this in the upstream OpenStack gates). It would be interesting to see something running that regularly checks for CVE’s in the libraries that _could_ be included in OpenStack, (library requirements within OpenStack often include more than one version) and bumps the version to the next safest and submits a change request for manual verification etc. -Rob From: Adam Heczko [mailto:ahec...@mirantis.com] Sent: 03 August 2015 23:18 To: OpenStack Development Mailing List (not for usage questions) Cc: Heath, Constanza M; Ding, Jian-feng; Demeter, Michael; Bhandaru, Malini K Subject: Re: [openstack-dev] Would people see a value in the cve-check-tool? Hi Elena, the tool looks very interesting. Maybe try to spread out this proposal also through openstack-security@ ML. BTW, I can't find the wrapper mentioned - am I missing something? Regards, Adam On Mon, Aug 3, 2015 at 11:08 PM, Reshetova, Elena elena.reshet...@intel.commailto:elena.reshet...@intel.com wrote: Hi, We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process? A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies. The tool is located here: https://github.com/ikeydoherty/cve-check-tool I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs). Best Regards, Elena. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Adam Heczko Security Engineer @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Would people see a value in the cve-check-tool?
On 8/4/15, 13:17, Clark, Robert Graham robert.cl...@hp.com wrote: Hi Elena, This is interesting work, thanks for posting it (and for posting it here on openstack-dev, we are trying to wind down the security ML) though maybe use the [Security] tag in the subject line next time. I think this is a very interesting project, though it’s unclear to me who might be the targeted users for this? It seems like it would make the most sense for this to be in the gate. Now this could be the standard build gates (Jenkins etc) but I’m not sure how much sense that makes on its own, after all most production consumers (those who care about CVEs) of OpenStack are probably not consuming it vanilla from source but are more likely to be consuming it from a vendor who’s already packaged it up. In the latter case, I’m sure vendors would find this tool very useful, we do something similar at HP today but I’m sure a tool like this would add value and it’s probably something we could contribute to. As I write this I’ve realised that there would be an interesting possibility in the former case (putting this in the upstream OpenStack gates). It would be interesting to see something running that regularly checks for CVE’s in the libraries that _could_ be included in OpenStack, (library requirements within OpenStack often include more than one version) and bumps the version to the next safest and submits a change request for manual verification etc. -Rob Since requests was already brought up in the discussion below and we're discussing potential uses for this in the gate, let me throw in my two cents as a requests core developer. The mere presence of a CVE id for a release does not in anyway imply an effect on OpenStack. In the CVEs in question (which Elena referred to) we have three separate issues: 1. Authentication credentials being sent on redirect to the wrong domain, e.g., attempt to authenticate to example.com which redirects to example.org and we would faithfully continue to attempt to authenticate. 2. See 1 but for proxies 3. Cookies sent with a redirect to a different domain were set for the domain we were redirected to instead of the domain we were redirected from. When I tried bumping the version for the first two, we had a discussion about the impact to OpenStack and it was decided that there wasn't a necessity to bump the version. There was no need to have a discussion about 3 because (as far as I'm aware) there isn't any service that uses cookies so that also doesn't have any effect. Being aware of these CVEs is one thing and would be nice. If we can determine that a CVE affects us, we most certainly should bump the minimum required version of that library in OpenStack. That said, part of the argument against increasing the lower bound on requests (at the time) was due to packagers not wanting to or being able to (I forget which) package the newer version (and no the review was not sent to a stable/* branch). So if we're going to be conflicting with downstream re-distributors, then this might be harder than we think. I have to agree that this is something that some Vendors will find useful. I suspect stackforge/os-ansible-deployment and stackforge/kolla will both find this useful as they both build OpenStack from source (although for the latter it is an option rather than a requirement). For Vendors depending distro packaged OpenStack (MOS if I remember correctly uses Debian's OpenStack packages), this will be of no interest and may be a waste of time. For example, Debian and Ubuntu should both be packaging python-requests-2.2.1 (this in fact is a reason why we had gate failures when urllib3 1.11 was released) but it should absolutely be patched for all three CVEs (making it not exactly 2.2.1 but that's besides the point). Those vendors should be trusting their curated packages to be properly patched for them. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Would people see a value in the cve-check-tool?
On 2015-08-04 18:17:13 + (+), Clark, Robert Graham wrote: [...] As I write this I’ve realised that there would be an interesting possibility in the former case (putting this in the upstream OpenStack gates). It would be interesting to see something running that regularly checks for CVE’s in the libraries that _could_ be included in OpenStack, (library requirements within OpenStack often include more than one version) and bumps the version to the next safest and submits a change request for manual verification etc. On a separate (private) E-mail thread where I recommended restarting this discussion here in public, that was more or less the intent. We have a mechanism for the openstack/requirements repo presently which resolves the current highest versions of all dependencies (including all their transitive dependencies) declared in the global-requirements.txt file and updates a file called upper-constraints.txt with the result. The proposed check tool could, in theory, consume this upper-constraints.txt and so run and report periodically on the state of package versions declared in that file. To take things a step further, when someone proposes a change to global-requirements.txt, a check job could generate the new upper-constraints.txt which would result from that and feed it into this CVE tool, reporting back on whether that proposed change would bring in any known-vulnerable versions of packages. This would most likely operate only in an advisory fashion, providing information to reviewers of requirements changes and any other interested parties, since I can envision circumstances under which its results would need to be temporarily ignored/overridden. All that is to say, I think the infrastructure integration for this is pretty straightforward. What I'd rather see first is people trying out the tool, finding out what it tells us about the present state of our requirements list, whether it's reliable or needs further work, whether its featureset is already sufficient, et cetera. -- Jeremy Stanley signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Would people see a value in the cve-check-tool?
On 2015-08-04 20:37:37 + (+), Ian Cordasco wrote: [...] When I tried bumping the version for the first two, we had a discussion about the impact to OpenStack and it was decided that there wasn't a necessity to bump the version. There was no need to have a discussion about 3 because (as far as I'm aware) there isn't any service that uses cookies so that also doesn't have any effect. Being aware of these CVEs is one thing and would be nice. If we can determine that a CVE affects us, we most certainly should bump the minimum required version of that library in OpenStack. That said, part of the argument against increasing the lower bound on requests (at the time) was due to packagers not wanting to or being able to (I forget which) package the newer version (and no the review was not sent to a stable/* branch). So if we're going to be conflicting with downstream re-distributors, then this might be harder than we think. [...] I don't think the intent of this is to blacklist potentially vulnerable versions of dependencies, it's to help us not prevent the use of fixed versions. Evaluating our upper-constraints.txt would in theory let us know: 1. dependencies which have been basically abandoned by their caretakers and have fallen into a vulnerable state, so potentially need assistance from our community 2. dependencies on which we have a restrictive upper bound, which prevents our users from consuming a release where some vulnerability has been fixed Arguably also 3. lots of CVEs which aren't applicable for some reason, so we likely need a means to whitelist those and filter them from the report. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Would people see a value in the cve-check-tool?
Hi Elena, the tool looks very interesting. Maybe try to spread out this proposal also through openstack-security@ ML. BTW, I can't find the wrapper mentioned - am I missing something? Regards, Adam On Mon, Aug 3, 2015 at 11:08 PM, Reshetova, Elena elena.reshet...@intel.com wrote: Hi, We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process? A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies. The tool is located here: https://github.com/ikeydoherty/cve-check-tool I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs). Best Regards, Elena. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Adam Heczko Security Engineer @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
