Commit | Line | Data |
---|---|---|
b135fd4a JL |
1 | =encoding utf-8 |
2 | ||
3 | =for stopwords | |
4 | CVE perlsecpolicy SV perl Perl SDBM HackerOne Mitre | |
5 | ||
6 | =head1 NAME | |
7 | ||
8 | perlsecpolicy - Perl security report handling policy | |
9 | ||
10 | =head1 DESCRIPTION | |
11 | ||
12 | The Perl project takes security issues seriously. | |
13 | ||
14 | The responsibility for handling security reports in a timely and | |
15 | effective manner has been delegated to a security team composed | |
16 | of a subset of the Perl core developers. | |
17 | ||
18 | This document describes how the Perl security team operates and | |
19 | how the team evaluates new security reports. | |
20 | ||
21 | =head1 REPORTING SECURITY ISSUES IN PERL | |
22 | ||
23 | If you believe you have found a security vulnerability in the Perl | |
24 | interpreter or modules maintained in the core Perl codebase, | |
25 | email the details to | |
26 | L<perl-security@perl.org|mailto:perl-security@perl.org>. | |
27 | This address is a closed membership mailing list monitored by the Perl | |
28 | security team. | |
29 | ||
30 | You should receive an initial response to your report within 72 hours. | |
31 | If you do not receive a response in that time, please contact | |
dcbafa45 | 32 | the L<Perl Steering Council|mailto:steering-council@perl.org>. |
b135fd4a JL |
33 | |
34 | When members of the security team reply to your messages, they will | |
35 | generally include the perl-security@perl.org address in the "To" or "CC" | |
36 | fields of the response. This allows all of the security team to follow | |
37 | the discussion and chime in as needed. Use the "Reply-all" functionality | |
38 | of your email client when you send subsequent responses so that the | |
39 | entire security team receives the message. | |
40 | ||
41 | The security team will evaluate your report and make an initial | |
42 | determination of whether it is likely to fit the scope of issues the | |
43 | team handles. General guidelines about how this is determined are | |
44 | detailed in the L</WHAT ARE SECURITY ISSUES> section. | |
45 | ||
46 | If your report meets the team's criteria, an issue will be opened in the | |
47 | team's private issue tracker and you will be provided the issue's ID number. | |
48 | Issue identifiers have the form perl-security#NNN. Include this identifier | |
49 | with any subsequent messages you send. | |
50 | ||
51 | The security team will send periodic updates about the status of your | |
52 | issue and guide you through any further action that is required to complete | |
53 | the vulnerability remediation process. The stages vulnerabilities typically | |
54 | go through are explained in the L</HOW WE DEAL WITH SECURITY ISSUES> | |
55 | section. | |
56 | ||
57 | =head1 WHAT ARE SECURITY ISSUES | |
58 | ||
59 | A vulnerability is a behavior of a software system that compromises the | |
60 | system's expected confidentiality, integrity or availability protections. | |
61 | ||
62 | A security issue is a bug in one or more specific components of a software | |
63 | system that creates a vulnerability. | |
64 | ||
65 | Software written in the Perl programming language is typically composed | |
66 | of many layers of software written by many different groups. It can be | |
67 | very complicated to determine which specific layer of a complex real-world | |
68 | application was responsible for preventing a vulnerable behavior, but this | |
69 | is an essential part of fixing the vulnerability. | |
70 | ||
71 | =head2 Software covered by the Perl security team | |
72 | ||
73 | The Perl security team handles security issues in: | |
74 | ||
75 | =over | |
76 | ||
77 | =item * | |
78 | ||
79 | The Perl interpreter | |
80 | ||
81 | =item * | |
82 | ||
83 | The Perl modules shipped with the interpreter that are developed in the core | |
84 | Perl repository | |
85 | ||
86 | =item * | |
87 | ||
88 | The command line tools shipped with the interpreter that are developed in the | |
89 | core Perl repository | |
90 | ||
91 | =back | |
92 | ||
93 | Files under the F<cpan/> directory in Perl's repository and release tarballs are | |
47199f63 KE |
94 | developed and maintained independently. The Perl security team does not |
95 | directly handle security issues for these modules, but since this code is | |
96 | bundled with Perl, we will assist in forwarding the issue to the relevant | |
97 | maintainer(s) and you can still report these issues to us in secrecy. | |
b135fd4a JL |
98 | |
99 | =head2 Bugs that may qualify as security issues in Perl | |
100 | ||
101 | Perl is designed to be a fast and flexible general purpose programming | |
102 | language. The Perl interpreter and Perl modules make writing safe and | |
103 | secure applications easy, but they do have limitations. | |
104 | ||
105 | As a general rule, a bug in Perl needs to meet all of the following | |
106 | criteria to be considered a security issue: | |
107 | ||
108 | =over | |
109 | ||
110 | =item * | |
111 | ||
112 | The vulnerable behavior is not mentioned in Perl's documentation | |
113 | or public issue tracker. | |
114 | ||
115 | =item * | |
116 | ||
117 | The vulnerable behavior is not implied by an expected behavior. | |
118 | ||
119 | =item * | |
120 | ||
121 | The vulnerable behavior is not a generally accepted limitation of | |
122 | the implementation. | |
123 | ||
124 | =item * | |
125 | ||
126 | The vulnerable behavior is likely to be exposed to attack in | |
127 | otherwise secure applications written in Perl. | |
128 | ||
129 | =item * | |
130 | ||
131 | The vulnerable behavior provides a specific tangible benefit | |
132 | to an attacker that triggers the behavior. | |
133 | ||
134 | =back | |
135 | ||
136 | =head2 Bugs that do not qualify as security issues in Perl | |
137 | ||
138 | There are certain categories of bugs that are frequently reported to | |
139 | the security team that do not meet the criteria listed above. | |
140 | ||
141 | The following is a list of commonly reported bugs that are not | |
142 | handled as security issues. | |
143 | ||
144 | =head3 Feeding untrusted code to the interpreter | |
145 | ||
146 | The Perl parser is not designed to evaluate untrusted code. | |
147 | If your application requires the evaluation of untrusted code, it | |
148 | should rely on an operating system level sandbox for its security. | |
149 | ||
150 | =head3 Stack overflows due to excessive recursion | |
151 | ||
152 | Excessive recursion is often caused by code that does | |
153 | not enforce limits on inputs. The Perl interpreter assumes limits | |
154 | on recursion will be enforced by the application. | |
155 | ||
156 | =head3 Out of memory errors | |
157 | ||
158 | Common Perl constructs such as C<pack>, the C<x> operator, | |
159 | and regular expressions accept numeric quantifiers that control how | |
160 | much memory will be allocated to store intermediate values or results. | |
161 | If you allow an attacker to supply these quantifiers and consume all | |
162 | available memory, the Perl interpreter will not prevent it. | |
163 | ||
164 | =head3 Escape from a L<Safe> compartment | |
165 | ||
166 | L<Opcode> restrictions and L<Safe> compartments are not supported as | |
167 | security mechanisms. The Perl parser is not designed to evaluate | |
168 | untrusted code. | |
169 | ||
170 | =head3 Use of the C<p> and C<P> pack templates | |
171 | ||
172 | These templates are unsafe by design. | |
173 | ||
174 | =head3 Stack not reference-counted issues | |
175 | ||
176 | These bugs typically present as use-after-free errors or as assertion | |
177 | failures on the type of a C<SV>. Stack not reference-counted | |
178 | crashes usually occur because code is both modifying a reference or | |
179 | glob and using the values referenced by that glob or reference. | |
180 | ||
181 | This type of bug is a long standing issue with the Perl interpreter | |
182 | that seldom occurs in normal code. Examples of this type of bug | |
183 | generally assume that attacker-supplied code will be evaluated by | |
184 | the Perl interpreter. | |
185 | ||
186 | =head3 Thawing attacker-supplied data with L<Storable> | |
187 | ||
188 | L<Storable> is designed to be a very fast serialization format. | |
189 | It is not designed to be safe for deserializing untrusted inputs. | |
190 | ||
191 | =head3 Using attacker supplied L<SDBM_File> databases | |
192 | ||
193 | The L<SDBM_File> module is not intended for use with untrusted SDBM | |
194 | databases. | |
195 | ||
196 | =head3 Badly encoded UTF-8 flagged scalars | |
197 | ||
198 | This type of bug occurs when the C<:utf8> PerlIO layer is used to | |
199 | read badly encoded data, or other mechanisms are used to directly | |
200 | manipulate the UTF-8 flag on an SV. | |
201 | ||
202 | A badly encoded UTF-8 flagged SV is not a valid SV. Code that | |
203 | creates SV's in this fashion is corrupting Perl's internal state. | |
204 | ||
205 | =head3 Issues that exist only in blead, or in a release candidate | |
206 | ||
207 | The blead branch and Perl release candidates do not receive security | |
208 | support. Security defects that are present only in pre-release | |
209 | versions of Perl are handled through the normal bug reporting and | |
210 | resolution process. | |
211 | ||
212 | =head3 CPAN modules or other Perl project resources | |
213 | ||
214 | The Perl security team is focused on the Perl interpreter and modules | |
215 | maintained in the core Perl codebase. The team has no special access | |
216 | to fix CPAN modules, applications written in Perl, Perl project websites, | |
217 | Perl mailing lists or the Perl IRC servers. | |
218 | ||
219 | =head3 Emulated POSIX behaviors on Windows systems | |
220 | ||
221 | The Perl interpreter attempts to emulate C<fork>, C<system>, C<exec> | |
222 | and other POSIX behaviors on Windows systems. This emulation has many | |
223 | quirks that are extensively documented in Perl's public issue tracker. | |
224 | Changing these behaviors would cause significant disruption for existing | |
225 | users on Windows. | |
226 | ||
227 | =head2 Bugs that require special categorization | |
228 | ||
229 | Some bugs in the Perl interpreter occur in areas of the codebase that are | |
230 | both security sensitive and prone to failure during normal usage. | |
231 | ||
232 | =head3 Regular expressions | |
233 | ||
234 | Untrusted regular expressions are generally safe to compile and match against | |
235 | with several caveats. The following behaviors of Perl's regular expression | |
236 | engine are the developer's responsibility to constrain. | |
237 | ||
238 | The evaluation of untrusted regular expressions while C<use re 'eval';> is | |
239 | in effect is never safe. | |
240 | ||
241 | Regular expressions are not guaranteed to compile or evaluate in any specific | |
242 | finite time frame. | |
243 | ||
244 | Regular expressions may consume all available system memory when they are | |
245 | compiled or evaluated. | |
246 | ||
247 | Regular expressions may cause excessive recursion that halts the perl | |
248 | interpreter. | |
249 | ||
250 | As a general rule, do not expect Perl's regular expression engine to | |
251 | be resistant to denial of service attacks. | |
252 | ||
253 | =head3 L<DB_File>, L<ODBM_File>, or L<GDBM_File> databases | |
254 | ||
255 | These modules rely on external libraries to interact with database files. | |
256 | ||
257 | Bugs caused by reading and writing these file formats are generally caused | |
258 | by the underlying library implementation and are not security issues in | |
259 | Perl. | |
260 | ||
261 | Bugs where Perl mishandles unexpected valid return values from the underlying | |
262 | libraries may qualify as security issues in Perl. | |
263 | ||
264 | =head3 Algorithmic complexity attacks | |
265 | ||
266 | The perl interpreter is reasonably robust to algorithmic complexity | |
267 | attacks. It is not immune to them. | |
268 | ||
269 | Algorithmic complexity bugs that depend on the interpreter processing | |
270 | extremely large amounts of attacker supplied data are not generally handled | |
271 | as security issues. | |
272 | ||
273 | See L<perlsec/Algorithmic Complexity Attacks> for additional information. | |
274 | ||
275 | =head1 HOW WE DEAL WITH SECURITY ISSUES | |
276 | ||
277 | The Perl security team follows responsible disclosure practices. Security issues | |
278 | are kept secret until a fix is readily available for most users. This minimizes | |
279 | inherent risks users face from vulnerabilities in Perl. | |
280 | ||
281 | Hiding problems from the users temporarily is a necessary trade-off to keep | |
282 | them safe. Hiding problems from users permanently is not the goal. | |
283 | ||
284 | When you report a security issue privately to the | |
285 | L<perl-security@perl.org|mailto:perl-security@perl.org> contact address, we | |
286 | normally expect you to follow responsible disclosure practices in the handling | |
287 | of the report. If you are unable or unwilling to keep the issue secret until | |
288 | a fix is available to users you should state this clearly in the initial | |
289 | report. | |
290 | ||
291 | The security team's vulnerability remediation workflow is intended to be as | |
292 | open and transparent as possible about the state of your security report. | |
293 | ||
294 | =head2 Perl's vulnerability remediation workflow | |
295 | ||
296 | =head3 Initial contact | |
297 | ||
298 | New vulnerability reports will receive an initial reply within 72 hours | |
299 | from the time they arrive at the security team's mailing list. If you do | |
93696217 | 300 | not receive any response in that time, contact the |
dcbafa45 | 301 | L<Perl Steering Council|mailto:steering-council@perl.org>. |
b135fd4a JL |
302 | |
303 | The initial response sent by the security team will confirm your message was | |
304 | received and provide an estimated time frame for the security team's | |
305 | triage analysis. | |
306 | ||
307 | =head3 Initial triage | |
308 | ||
309 | The security team will evaluate the report and determine whether or not | |
310 | it is likely to meet the criteria for handling as a security issue. | |
311 | ||
312 | The security team aims to complete the initial report triage within | |
313 | two weeks' time. Complex issues that require significant discussion or | |
314 | research may take longer. | |
315 | ||
316 | If the security report cannot be reproduced or does not meet the team's | |
317 | criteria for handling as a security issue, you will be notified by email | |
318 | and given an opportunity to respond. | |
319 | ||
320 | =head3 Issue ID assignment | |
321 | ||
322 | Security reports that pass initial triage analysis are turned into issues | |
323 | in the security team's private issue tracker. When a report progresses to | |
324 | this point you will be provided the issue ID for future reference. These | |
325 | identifiers have the format perl-security#NNN or Perl/perl-security#NNN. | |
326 | ||
327 | The assignment of an issue ID does not confirm that a security report | |
328 | represents a vulnerability in Perl. Many reports require further analysis | |
329 | to reach that determination. | |
330 | ||
331 | Issues in the security team's private tracker are used to collect details | |
332 | about the problem and track progress towards a resolution. These notes and | |
333 | other details are not made public when the issue is resolved. Keeping the | |
334 | issue notes private allows the security team to freely discuss attack | |
335 | methods, attack tools, and other related private issues. | |
336 | ||
337 | =head3 Development of patches | |
338 | ||
339 | Members of the security team will inspect the report and related code in | |
340 | detail to produce fixes for supported versions of Perl. | |
341 | ||
342 | If the team discovers that the reported issue does not meet the team's | |
343 | criteria at this stage, you will be notified by email and given an | |
344 | opportunity to respond before the issue is closed. | |
345 | ||
346 | The team may discuss potential fixes with you or provide you with | |
347 | patches for testing purposes during this time frame. No information | |
348 | should be shared publicly at this stage. | |
349 | ||
350 | =head3 CVE ID assignment | |
351 | ||
352 | Once an issue is fully confirmed and a potential fix has been found, | |
353 | the security team will request a CVE identifier for the issue to use | |
354 | in public announcements. | |
355 | ||
356 | Details like the range of vulnerable Perl versions and identities | |
357 | of the people that discovered the flaw need to be collected to submit | |
358 | the CVE ID request. | |
359 | ||
360 | The security team may ask you to clarify the exact name we should use | |
361 | when crediting discovery of the issue. The | |
362 | L</Vulnerability credit and bounties> section of this document | |
363 | explains our preferred format for this credit. | |
364 | ||
365 | Once a CVE ID has been assigned, you will be notified by email. | |
366 | The vulnerability should not be discussed publicly at this stage. | |
367 | ||
368 | =head3 Pre-release notifications | |
369 | ||
370 | When the security team is satisfied that the fix for a security issue | |
371 | is ready to release publicly, a pre-release notification | |
372 | announcement is sent to the major redistributors of Perl. | |
373 | ||
374 | This pre-release announcement includes a list of Perl versions that | |
375 | are affected by the flaw, an analysis of the risks to users, patches | |
376 | the security team has produced, and any information about mitigations | |
377 | or backporting fixes to older versions of Perl that the security team | |
378 | has available. | |
379 | ||
380 | The pre-release announcement will include a specific target date | |
381 | when the issue will be announced publicly. The time frame between | |
382 | the pre-release announcement and the release date allows redistributors | |
383 | to prepare and test their own updates and announcements. During this | |
384 | period the vulnerability details and fixes are embargoed and should not | |
385 | be shared publicly. This embargo period may be extended further if | |
386 | problems are discovered during testing. | |
387 | ||
388 | You will be sent the portions of pre-release announcements that are | |
389 | relevant to the specific issue you reported. This email will include | |
390 | the target release date. Additional updates will be sent if the | |
391 | target release date changes. | |
392 | ||
393 | =head3 Pre-release testing | |
394 | ||
395 | The Perl security team does not directly produce official Perl | |
396 | releases. The team releases security fixes by placing commits | |
397 | in Perl's public git repository and sending announcements. | |
398 | ||
399 | Many users and redistributors prefer using official Perl releases | |
400 | rather than applying patches to an older release. The security | |
401 | team works with Perl's release managers to make this possible. | |
402 | ||
403 | New official releases of Perl are generally produced and tested | |
404 | on private systems during the pre-release embargo period. | |
405 | ||
406 | =head3 Release of fixes and announcements | |
407 | ||
408 | At the end of the embargo period the security fixes will be | |
409 | committed to Perl's public git repository and announcements will be | |
410 | sent to the L<perl5-porters|https://lists.perl.org/list/perl5-porters.html> | |
411 | and L<oss-security|https://oss-security.openwall.org/wiki/mailing-lists/oss-security> | |
412 | mailing lists. | |
413 | ||
414 | If official Perl releases are ready, they will be published at this time | |
415 | and announced on the L<perl5-porters|https://lists.perl.org/list/perl5-porters.html> | |
416 | mailing list. | |
417 | ||
418 | The security team will send a follow-up notification to everyone that | |
419 | participated in the pre-release embargo period once the release process is | |
420 | finished. Vulnerability reporters and Perl redistributors should not publish | |
421 | their own announcements or fixes until the Perl security team's release process | |
422 | is complete. | |
423 | ||
424 | =head2 Publicly known and zero-day security issues | |
425 | ||
426 | The security team's vulnerability remediation workflow assumes that issues | |
427 | are reported privately and kept secret until they are resolved. This isn't | |
428 | always the case and information occasionally leaks out before a fix is ready. | |
429 | ||
430 | In these situations the team must decide whether operating in secret increases | |
431 | or decreases the risk to users of Perl. In some cases being open about | |
432 | the risk a security issue creates will allow users to defend against it, | |
433 | in other cases calling attention to an unresolved security issue will | |
434 | make it more likely to be misused. | |
435 | ||
436 | =head3 Zero-day security issues | |
437 | ||
438 | If an unresolved critical security issue in Perl is being actively abused to | |
439 | attack systems the security team will send out announcements as rapidly as | |
440 | possible with any mitigations the team has available. | |
441 | ||
442 | Perl's public defect tracker will be used to handle the issue so that additional | |
443 | information, fixes, and CVE IDs are visible to affected users as rapidly as | |
444 | possible. | |
445 | ||
446 | =head3 Other leaks of security issue information | |
447 | ||
448 | Depending on the prominence of the information revealed about a security | |
449 | issue and the issue's risk of becoming a zero-day attack, the security team may | |
450 | skip all or part of its normal remediation workflow. | |
451 | ||
452 | If the security team learns of a significant security issue after it has been | |
453 | identified and resolved in Perl's public issue tracker, the team will | |
454 | request a CVE ID and send an announcement to inform users. | |
455 | ||
456 | =head2 Vulnerability credit and bounties | |
457 | ||
458 | The Perl project appreciates the effort security researchers | |
459 | invest in making Perl safe and secure. | |
460 | ||
461 | Since much of this work is hidden from the public, crediting | |
462 | researchers publicly is an important part of the vulnerability | |
463 | remediation process. | |
464 | ||
465 | =head3 Credits in vulnerability announcements | |
466 | ||
467 | When security issues are fixed we will attempt to credit the specific | |
468 | researcher(s) that discovered the flaw in our announcements. | |
469 | ||
470 | Credits are announced using the researcher's preferred full name. | |
471 | ||
472 | If the researcher's contributions were funded by a specific company or | |
473 | part of an organized vulnerability research project, we will include | |
474 | a short name for this group at the researcher's request. | |
475 | ||
476 | Perl's announcements are written in the English language using the 7bit | |
477 | ASCII character set to be reproducible in a variety of formats. We | |
478 | do not include hyperlinks, domain names or marketing material with these | |
479 | acknowledgments. | |
480 | ||
481 | In the event that proper credit for vulnerability discovery cannot be | |
482 | established or there is a disagreement between the Perl security team | |
483 | and the researcher about how the credit should be given, it will be | |
484 | omitted from announcements. | |
485 | ||
486 | =head3 Bounties for Perl vulnerabilities | |
487 | ||
488 | The Perl project is a non-profit volunteer effort. We do not provide | |
489 | any monetary rewards for reporting security issues in Perl. | |
490 | ||
491 | The L<Internet Bug Bounty|https://internetbugbounty.org/> offers monetary | |
492 | rewards for some Perl security issues after they are fully resolved. The | |
493 | terms of this program are available at L<HackerOne|https://hackerone.com/ibb-perl>. | |
494 | ||
495 | This program is not run by the Perl project or the Perl security team. | |
496 | ||
497 | =cut |