Re: [ovs-dev] [PATCH] SECURITY.md: Add advisory document details.
Yep, looks sensible... Acked-by: Ryan Moats "dev" wrote on 03/29/2016 01:07:53 PM: > From: Ben Pfaff > To: dev@openvswitch.org > Cc: Ben Pfaff > Date: 03/29/2016 01:09 PM > Subject: [ovs-dev] [PATCH] SECURITY.md: Add advisory document details. > Sent by: "dev" > > Signed-off-by: Ben Pfaff > --- > SECURITY.md | 104 + > --- > 1 file changed, 100 insertions(+), 4 deletions(-) > > diff --git a/SECURITY.md b/SECURITY.md > index 08a6ed8..33b85b5 100644 > --- a/SECURITY.md > +++ b/SECURITY.md > @@ -101,16 +101,112 @@ determines that it is not a realistic vulnerability. > Step 3a: Document > > > -The security team develops a security advisory document. The document > -credits the reporter and describes the vulnerability, including all of > -the relevant information from the assessment in step 2. The security > +The security team develops a security advisory document. The security > team may, at its discretion, include the reporter (via "CC") in > developing the security advisory document, but in any case should > accept feedback from the reporter before finalizing the document. > - > When the document is final, the security team should obtain a CVE for > the vulnerability from a CNA (https://cve.mitre.org/cve/cna.html). > > +The document credits the reporter and describes the vulnerability, > +including all of the relevant information from the assessment in step > +2. Suitable sections for the document include: > + > +* Title: The CVE identifier, a short description of the > + vulnerability. The title should mention Open vSwitch. > + > + In email, the title becomes the subject. Pre-release advisories > + are often passed around in encrypted email, which have plaintext > + subjects, so the title should not be too specific. > + > +* Description: A few paragraphs describing the general > + characteristics of the vulnerability, including the versions of > + Open vSwitch that are vulnerable, the kind of attack that > + exposes the vulnerability, and potential consequences of the > + attack. > + > + The description should re-state the CVE identifier, in case the > + subject is lost when an advisory is sent over email. > + > +* Mitigation: How an Open vSwitch administrator can minimize the > + potential for exploitation of the vulnerability, before applying > + a fix. If no mitigation is possible or recommended, explain > + why, to reduce the chance that at-risk users believe they are > + not at risk. > + > +* Fix: Describe how to fix the vulnerability, perhaps in terms of > + applying a source patch. The patch or patches themselves, if > + included in the email, should be at the very end of the advisory > + to reduce the risk that a reader would stop reading at this > + point. > + > +* Recommendation: A concise description of the security team's > + recommendation to users. > + > +* Acknowledgments: Thank the reporters. > + > +* Vulnerability Check: A step-by-step procedure by which a user > + can determine whether an installed copy of Open vSwitch is > + vulnerable. > + > + The procedure should clearly describe how to interpret the > + results, including expected results in vulnerable and > + not-vulnerable cases. Thus, procedures that produce clear and > + easily distinguished results are preferred. > + > + The procedure should assume as little understanding of Open > + vSwitch as possible, to make it more likely that a competent > + administrator who does not specialize in Open vSwitch can > + perform it successfully. > + > + The procedure should have minimal dependencies on tools that are > + not widely installed. > + > + Given a choice, the procedure should be one that takes at least > + some work to turn into a useful exploit. For example, a > + procedure based on "ovs-appctl" commands, which require local > + administrator access, is preferred to one that sends test > + packets to a machine, which only requires network connectivity. > + > + The section should say which operating systems it is designed > + for. If the procedure is likely to be specific to particular > + architectures (e.g. x86-64, i386), it should state on which ones > + it has been tested. > + > + This section should state the risks of the procedure. For > + example. if it can crash Open vSwitch or disrupt packet > + forwarding, say so. > + > + It is more useful to explain how to check an installed and > + running Open vSwitch than one built locally from source, but if > + it is easy to use the procedure from a sandbox environment, it > + can be helpful to explain how to do so. > + > +* Patch: If a patch or patches are available, and it is practical > + to include them in the ema
Re: [ovs-dev] [PATCH] SECURITY.md: Add advisory document details.
> On Mar 29, 2016, at 11:07 AM, Ben Pfaff wrote: > > + This section should state the risks of the procedure. For > + example. if it can crash Open vSwitch or disrupt packet I think that should be a comma instead of a period. Thanks a lot for writing this up! Acked-by: Justin Pettit --Justin ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] SECURITY.md: Add advisory document details.
Thanks, applied to master. On Tue, Mar 29, 2016 at 12:27:24PM -0600, Ryan Moats wrote: > Yep, looks sensible... > > Acked-by: Ryan Moats > > "dev" wrote on 03/29/2016 01:07:53 PM: > > > From: Ben Pfaff > > To: dev@openvswitch.org > > Cc: Ben Pfaff > > Date: 03/29/2016 01:09 PM > > Subject: [ovs-dev] [PATCH] SECURITY.md: Add advisory document details. > > Sent by: "dev" > > > > Signed-off-by: Ben Pfaff > > --- > > SECURITY.md | 104 + > > --- > > 1 file changed, 100 insertions(+), 4 deletions(-) > > > > diff --git a/SECURITY.md b/SECURITY.md > > index 08a6ed8..33b85b5 100644 > > --- a/SECURITY.md > > +++ b/SECURITY.md > > @@ -101,16 +101,112 @@ determines that it is not a realistic > vulnerability. > > Step 3a: Document > > > > > > -The security team develops a security advisory document. The document > > -credits the reporter and describes the vulnerability, including all of > > -the relevant information from the assessment in step 2. The security > > +The security team develops a security advisory document. The security > > team may, at its discretion, include the reporter (via "CC") in > > developing the security advisory document, but in any case should > > accept feedback from the reporter before finalizing the document. > > - > > When the document is final, the security team should obtain a CVE for > > the vulnerability from a CNA (https://cve.mitre.org/cve/cna.html). > > > > +The document credits the reporter and describes the vulnerability, > > +including all of the relevant information from the assessment in step > > +2. Suitable sections for the document include: > > + > > +* Title: The CVE identifier, a short description of the > > + vulnerability. The title should mention Open vSwitch. > > + > > + In email, the title becomes the subject. Pre-release advisories > > + are often passed around in encrypted email, which have plaintext > > + subjects, so the title should not be too specific. > > + > > +* Description: A few paragraphs describing the general > > + characteristics of the vulnerability, including the versions of > > + Open vSwitch that are vulnerable, the kind of attack that > > + exposes the vulnerability, and potential consequences of the > > + attack. > > + > > + The description should re-state the CVE identifier, in case the > > + subject is lost when an advisory is sent over email. > > + > > +* Mitigation: How an Open vSwitch administrator can minimize the > > + potential for exploitation of the vulnerability, before applying > > + a fix. If no mitigation is possible or recommended, explain > > + why, to reduce the chance that at-risk users believe they are > > + not at risk. > > + > > +* Fix: Describe how to fix the vulnerability, perhaps in terms of > > + applying a source patch. The patch or patches themselves, if > > + included in the email, should be at the very end of the advisory > > + to reduce the risk that a reader would stop reading at this > > + point. > > + > > +* Recommendation: A concise description of the security team's > > + recommendation to users. > > + > > +* Acknowledgments: Thank the reporters. > > + > > +* Vulnerability Check: A step-by-step procedure by which a user > > + can determine whether an installed copy of Open vSwitch is > > + vulnerable. > > + > > + The procedure should clearly describe how to interpret the > > + results, including expected results in vulnerable and > > + not-vulnerable cases. Thus, procedures that produce clear and > > + easily distinguished results are preferred. > > + > > + The procedure should assume as little understanding of Open > > + vSwitch as possible, to make it more likely that a competent > > + administrator who does not specialize in Open vSwitch can > > + perform it successfully. > > + > > + The procedure should have minimal dependencies on tools that are > > + not widely installed. > > + > > + Given a choice, the procedure should be one that takes at least > > + some work to turn into a useful exploit. For example, a > > + procedure based on "ovs-appctl" commands, which require local > > + administrator access, is preferred to one that sends test > > + packets to a machine, which only requires network connectivity. > > + > > + The section should say which operating systems it is designed > > + for. If the procedure is likely to be specific to particular > > + architectures (e.g. x86-64, i386), it should state on which ones > > + it has been tested. > > + > > + This section should state the risks of the procedure. For > > + example. if it can crash Open vSwitch or disrupt packet > > + forwarding, say so. > > + > > + It is more useful to explain how to check an installed and
Re: [ovs-dev] [PATCH] SECURITY.md: Add advisory document details.
On Tue, Mar 29, 2016 at 12:26:33PM -0700, Justin Pettit wrote: > > > On Mar 29, 2016, at 11:07 AM, Ben Pfaff wrote: > > > > + This section should state the risks of the procedure. For > > + example. if it can crash Open vSwitch or disrupt packet > > I think that should be a comma instead of a period. > > Thanks a lot for writing this up! > > Acked-by: Justin Pettit Thanks, applied to master with that fix. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
