]>
Commit | Line | Data |
---|---|---|
f0664242 BP |
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. | |
b13bfc3c AK |
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 | ||
f0664242 BP |
32 | Here are some examples of vulnerabilities to which one would expect to |
33 | apply this process: | |
34 | ||
b13bfc3c AK |
35 | * A crafted packet that causes a kernel or userspace crash |
36 | (Availability). | |
f0664242 BP |
37 | |
38 | * A flow translation bug that misforwards traffic in a way likely | |
b13bfc3c | 39 | to hop over security boundaries (Integrity). |
f0664242 BP |
40 | |
41 | * An OpenFlow protocol bug that allows a controller to read | |
b13bfc3c | 42 | arbitrary files from the file system (Confidentiality). |
f0664242 BP |
43 | |
44 | * Misuse of the OpenSSL library that allows bypassing certificate | |
b13bfc3c | 45 | checks (Integrity). |
f0664242 BP |
46 | |
47 | * A bug (memory corruption, overflow, ...) that allows one to | |
48 | modify the behaviour of OVS through external configuration | |
b13bfc3c | 49 | interfaces such as OVSDB (Integrity). |
f0664242 | 50 | |
b13bfc3c AK |
51 | * Privileged information is exposed to unprivileged users |
52 | (Confidentiality). | |
f0664242 BP |
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 | ||
b13bfc3c AK |
70 | Reporters may ask for a GPG key while initiating contact with the |
71 | security team to deliver more sensitive reports. | |
72 | ||
f0664242 BP |
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 | ||
bd5e61fd | 104 | The security team develops a security advisory document. The security |
f0664242 BP |
105 | team may, at its discretion, include the reporter (via "CC") in |
106 | developing the security advisory document, but in any case should | |
107 | accept feedback from the reporter before finalizing the document. | |
f0664242 BP |
108 | When the document is final, the security team should obtain a CVE for |
109 | the vulnerability from a CNA (https://cve.mitre.org/cve/cna.html). | |
110 | ||
bd5e61fd BP |
111 | The document credits the reporter and describes the vulnerability, |
112 | including all of the relevant information from the assessment in step | |
113 | 2. Suitable sections for the document include: | |
114 | ||
115 | * Title: The CVE identifier, a short description of the | |
116 | vulnerability. The title should mention Open vSwitch. | |
117 | ||
118 | In email, the title becomes the subject. Pre-release advisories | |
119 | are often passed around in encrypted email, which have plaintext | |
120 | subjects, so the title should not be too specific. | |
121 | ||
122 | * Description: A few paragraphs describing the general | |
123 | characteristics of the vulnerability, including the versions of | |
124 | Open vSwitch that are vulnerable, the kind of attack that | |
125 | exposes the vulnerability, and potential consequences of the | |
126 | attack. | |
127 | ||
128 | The description should re-state the CVE identifier, in case the | |
129 | subject is lost when an advisory is sent over email. | |
130 | ||
131 | * Mitigation: How an Open vSwitch administrator can minimize the | |
132 | potential for exploitation of the vulnerability, before applying | |
133 | a fix. If no mitigation is possible or recommended, explain | |
134 | why, to reduce the chance that at-risk users believe they are | |
135 | not at risk. | |
136 | ||
137 | * Fix: Describe how to fix the vulnerability, perhaps in terms of | |
138 | applying a source patch. The patch or patches themselves, if | |
139 | included in the email, should be at the very end of the advisory | |
140 | to reduce the risk that a reader would stop reading at this | |
141 | point. | |
142 | ||
143 | * Recommendation: A concise description of the security team's | |
144 | recommendation to users. | |
145 | ||
146 | * Acknowledgments: Thank the reporters. | |
147 | ||
148 | * Vulnerability Check: A step-by-step procedure by which a user | |
149 | can determine whether an installed copy of Open vSwitch is | |
150 | vulnerable. | |
151 | ||
152 | The procedure should clearly describe how to interpret the | |
153 | results, including expected results in vulnerable and | |
154 | not-vulnerable cases. Thus, procedures that produce clear and | |
155 | easily distinguished results are preferred. | |
156 | ||
157 | The procedure should assume as little understanding of Open | |
158 | vSwitch as possible, to make it more likely that a competent | |
159 | administrator who does not specialize in Open vSwitch can | |
160 | perform it successfully. | |
161 | ||
162 | The procedure should have minimal dependencies on tools that are | |
163 | not widely installed. | |
164 | ||
165 | Given a choice, the procedure should be one that takes at least | |
166 | some work to turn into a useful exploit. For example, a | |
167 | procedure based on "ovs-appctl" commands, which require local | |
168 | administrator access, is preferred to one that sends test | |
169 | packets to a machine, which only requires network connectivity. | |
170 | ||
171 | The section should say which operating systems it is designed | |
172 | for. If the procedure is likely to be specific to particular | |
173 | architectures (e.g. x86-64, i386), it should state on which ones | |
174 | it has been tested. | |
175 | ||
176 | This section should state the risks of the procedure. For | |
177 | example, if it can crash Open vSwitch or disrupt packet | |
178 | forwarding, say so. | |
179 | ||
180 | It is more useful to explain how to check an installed and | |
181 | running Open vSwitch than one built locally from source, but if | |
182 | it is easy to use the procedure from a sandbox environment, it | |
183 | can be helpful to explain how to do so. | |
184 | ||
185 | * Patch: If a patch or patches are available, and it is practical | |
186 | to include them in the email, put them at the end. Format them | |
187 | as described in CONTRIBUTING.md, that is, as output by "git | |
188 | format-patch". | |
189 | ||
190 | The patch subjects should include the version for which they are | |
191 | suited, e.g. "[PATCH branch-2.3]" for a patch against Open | |
192 | vSwitch 2.3.x. If there are multiple patches for multiple | |
193 | versions of Open vSwitch, put them in separate sections with | |
194 | clear titles. | |
195 | ||
196 | Multiple patches for a single version of Open vSwitch, that must | |
197 | be stacked on top of each other to fix a single vulnerability, | |
198 | are undesirable because users are less likely to apply all of | |
199 | them correctly and in the correct order. | |
200 | ||
201 | Each patch should include a Vulnerability tag with the CVE | |
202 | identifier, a Reported-by tag or tags to credit the reporters, | |
203 | and a Signed-off-by tag to acknowledge the Developer's | |
204 | Certificate of Origin. It should also include other appropriate | |
205 | tags, such as Acked-by tags obtained during review. | |
206 | ||
207 | CVE-2016-2074 is an example advisory document, available at: | |
208 | http://openvswitch.org/pipermail/announce/2016-March/000082.html | |
209 | ||
f0664242 BP |
210 | |
211 | Step 3b: Fix | |
212 | ------------ | |
213 | ||
214 | Steps 3a and 3b may proceed in parallel. | |
215 | ||
216 | The security team develops and obtains (private) reviews for patches | |
217 | that fix the vulnerability. If necessary, the security team pulls in | |
bb6c5fad | 218 | additional developers, who must agree to maintain confidentiality. |
f0664242 BP |
219 | |
220 | ||
221 | Step 4: Embargoed Disclosure | |
222 | ---------------------------- | |
223 | ||
224 | The security advisory and patches are sent to downstream stakeholders, | |
48beaa85 FL |
225 | with an embargo date and time set from the time sent. Downstream |
226 | stakeholders are expected not to deploy or disclose patches until | |
227 | the embargo is passed. | |
228 | ||
229 | A disclosure date is negotiated by the security team working with the | |
230 | bug submitter as well as vendors. However, the Open vSwitch security | |
231 | team holds the final say when setting a disclosure date. The timeframe | |
232 | for disclosure is from immediate (esp. if it's already publicly known) | |
233 | to a few weeks. As a basic default policy, we expect report date to | |
24de3634 | 234 | disclosure date to be 10 to 15 business days. |
f0664242 BP |
235 | |
236 | Operating system vendors are obvious downstream stakeholders. It may | |
237 | not be necessary to be too choosy about who to include: any major Open | |
238 | vSwitch user who is interested and can be considered trustworthy | |
239 | enough could be included. To become a downstream stakeholder, email | |
240 | the ovs-security mailing list. | |
241 | ||
b13bfc3c | 242 | If the vulnerability is already public, skip this step. |
f0664242 BP |
243 | |
244 | ||
b13bfc3c AK |
245 | Step 5: Public Disclosure |
246 | ------------------------- | |
f0664242 BP |
247 | |
248 | When the embargo expires, push the (reviewed) patches to appropriate | |
249 | branches, post the patches to the ovs-dev mailing list (noting that | |
250 | they have already been reviewed and applied), post the security | |
251 | advisory to appropriate mailing lists (ovs-announce, ovs-discuss), and | |
252 | post the security advisory on the Open vSwitch webpage. | |
253 | ||
bc57376a FL |
254 | When the patch is applied to LTS (long-term support) branches, a new |
255 | version should be released. | |
256 | ||
f0664242 BP |
257 | The security advisory should be GPG-signed by a security team member |
258 | with a key that is in a public web of trust. | |
259 | ||
260 | ||
b13bfc3c | 261 | Contact |
f0664242 BP |
262 | ======= |
263 | ||
264 | Report security vulnerabilities to the ovs-security mailing list: | |
265 | security@openvswitch.org | |
266 | ||
267 | Report problems with this document to the ovs-bugs mailing list: | |
268 | bugs@openvswitch.org | |
269 | ||
270 | Visit http://openvswitch.org/ to learn more about Open vSwitch. |