SECURITY.md

   1 Security Process
   2 ================
   3
   4 This is a proposed security vulnerability reporting and handling
   5 process for Open vSwitch.  It is based on the OpenStack vulnerability
   6 management process described at
   7 https://wiki.openstack.org/wiki/Vulnerability_Management.
   8
   9 The OVS security team coordinates vulnerability management using the
  10 ovs-security mailing list.  Membership in the security team and
  11 subscription to its mailing list consists of a small number of
  12 trustworthy people, as determined by rough consensus of the Open
  13 vSwitch committers on the ovs-committers mailing list.  The Open
  14 vSwitch security team should include Open vSwitch committers, to
  15 ensure prompt and accurate vulnerability assessments and patch review.
  16
  17 We encourage everyone involved in the security process to GPG-sign
  18 their emails.  We additionally encourage GPG-encrypting one-on-one
  19 conversations as part of the security process.
  20
  21
  22 What is a vulnerability?
  23 ------------------------
  24
  25 All vulnerabilities are bugs, but not every bug is a vulnerability.
  26 Here are some examples of vulnerabilities to which one would expect to
  27 apply this process:
  28
  29     * A crafted packet that causes a kernel or userspace crash.
  30
  31     * A flow translation bug that misforwards traffic in a way likely
  32       to hop over security boundaries.
  33
  34     * An OpenFlow protocol bug that allows a controller to read
  35       arbitrary files from the file system.
  36
  37     * Misuse of the OpenSSL library that allows bypassing certificate
  38       checks.
  39
  40     * A bug (memory corruption, overflow, ...) that allows one to
  41       modify the behaviour of OVS through external configuration
  42       interfaces such as OVSDB.
  43
  44     * Privileged information is exposed to unprivileged users.
  45
  46 If in doubt, please do use the vulnerability management process.  At
  47 worst, the response will be to report the bug through the usual
  48 channels.
  49
  50
  51 Step 1: Reception
  52 -----------------
  53
  54 To report an Open vSwitch vulnerability, send an email to the
  55 ovs-security mailing list (see "Contact" at the end of this document).
  56 A security team member should reply to the reporter acknowledging that
  57 the report has been received.
  58
  59 Please consider reporting the information mentioned in
  60 REPORTING-BUGS.md, where relevant.
  61
  62 The Linux kernel has its own vulnerability management process:
  63 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SecurityBugs
  64 Handling of vulnerabilities that affect both the Open vSwitch tree and
  65 the upstream Linux kernel should be reported through both processes.
  66 Please send your report as a single email to both the kernel and OVS
  67 security teams to allow those teams to most easily coordinate among
  68 themselves.
  69
  70
  71 Step 2: Assessment
  72 ------------------
  73
  74 The security team should discuss the vulnerability.  The reporter
  75 should be included in the discussion (via "CC") to an appropriate
  76 degree.
  77
  78 The assessment should determine which Open vSwitch versions are
  79 affected (e.g. every version, only the latest release, only unreleased
  80 versions), the privilege required to take advantage of the
  81 vulnerability (e.g. any network user, any local L2 network user, any
  82 local system user, connected OpenFlow controllers), the severity of
  83 the vulnerability, and how the vulnerability may be mitigated (e.g. by
  84 disabling a feature).
  85
  86 The treatment of the vulnerability could end here if the team
  87 determines that it is not a realistic vulnerability.
  88
  89
  90 Step 3a: Document
  91 ----------------
  92
  93 The security team develops a security advisory document.  The document
  94 credits the reporter and describes the vulnerability, including all of
  95 the relevant information from the assessment in step 2.  The security
  96 team may, at its discretion, include the reporter (via "CC") in
  97 developing the security advisory document, but in any case should
  98 accept feedback from the reporter before finalizing the document.
  99
 100 When the document is final, the security team should obtain a CVE for
 101 the vulnerability from a CNA (https://cve.mitre.org/cve/cna.html).
 102
 103
 104 Step 3b: Fix
 105 ------------
 106
 107 Steps 3a and 3b may proceed in parallel.
 108
 109 The security team develops and obtains (private) reviews for patches
 110 that fix the vulnerability.  If necessary, the security team pulls in
 111 additional developers, who must agree to maintain confidentiality.
 112
 113
 114 Step 4: Embargoed Disclosure
 115 ----------------------------
 116
 117 The security advisory and patches are sent to downstream stakeholders,
 118 with an embargo date and time set from the time sent.  Downstream
 119 stakeholders are expected not to deploy or disclose patches until
 120 the embargo is passed.
 121
 122 A disclosure date is negotiated by the security team working with the
 123 bug submitter as well as vendors.  However, the Open vSwitch security
 124 team holds the final say when setting a disclosure date.  The timeframe
 125 for disclosure is from immediate (esp. if it's already publicly known)
 126 to a few weeks.  As a basic default policy, we expect report date to
 127 disclosure date to be 3~5 business days.
 128
 129 Operating system vendors are obvious downstream stakeholders.  It may
 130 not be necessary to be too choosy about who to include: any major Open
 131 vSwitch user who is interested and can be considered trustworthy
 132 enough could be included.  To become a downstream stakeholder, email
 133 the ovs-security mailing list.
 134
 135 If the vulnerability is public, skip this step.
 136
 137
 138 Step 5: Full Disclosure
 139 -----------------------
 140
 141 When the embargo expires, push the (reviewed) patches to appropriate
 142 branches, post the patches to the ovs-dev mailing list (noting that
 143 they have already been reviewed and applied), post the security
 144 advisory to appropriate mailing lists (ovs-announce, ovs-discuss), and
 145 post the security advisory on the Open vSwitch webpage.
 146
 147 The security advisory should be GPG-signed by a security team member
 148 with a key that is in a public web of trust.
 149
 150
 151 Contact
 152 =======
 153
 154 Report security vulnerabilities to the ovs-security mailing list:
 155 security@openvswitch.org
 156
 157 Report problems with this document to the ovs-bugs mailing list:
 158 bugs@openvswitch.org
 159
 160 Visit http://openvswitch.org/ to learn more about Open vSwitch.