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