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