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