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 directly handle security issues for these modules, but
80 since this code is bundled with Perl, we will assist in forwarding the
81 issue to the relevant maintainer(s) and you can still report these
82 issues to us in secrecy.
83 Bugs that may qualify as security issues in Perl
85 Perl is designed to be a fast and flexible general purpose programming
86 language. The Perl interpreter and Perl modules make writing safe and
87 secure applications easy, but they do have limitations.
88 As a general rule, a bug in Perl needs to meet all of the following
90 criteria to be considered a security issue:
91 • The vulnerable behavior is not mentioned in Perl's documentation or
93 public issue tracker.
94 • The vulnerable behavior is not implied by an expected behavior.
96 • The vulnerable behavior is not a generally accepted limitation of
98 the implementation.
99 • The vulnerable behavior is likely to be exposed to attack in
101 otherwise secure applications written in Perl.
102 • The vulnerable behavior provides a specific tangible benefit to an
104 attacker that triggers the behavior.
105 Bugs that do not qualify as security issues in Perl
107 There are certain categories of bugs that are frequently reported to
108 the security team that do not meet the criteria listed above.
109 The following is a list of commonly reported bugs that are not handled
111 as security issues.
112 Feeding untrusted code to the interpreter
114 The Perl parser is not designed to evaluate untrusted code. If your
116 application requires the evaluation of untrusted code, it should rely
117 on an operating system level sandbox for its security.
118 Stack overflows due to excessive recursion
120 Excessive recursion is often caused by code that does not enforce
122 limits on inputs. The Perl interpreter assumes limits on recursion will
123 be enforced by the application.
124 Out of memory errors
126 Common Perl constructs such as "pack", the "x" operator, and regular
128 expressions accept numeric quantifiers that control how much memory
129 will be allocated to store intermediate values or results. If you
130 allow an attacker to supply these quantifiers and consume all available
131 memory, the Perl interpreter will not prevent it.
132 Escape from a Safe compartment
134 Opcode restrictions and Safe compartments are not supported as security
136 mechanisms. The Perl parser is not designed to evaluate untrusted code.
137 Use of the "p" and "P" pack templates
139 These templates are unsafe by design.
141 Stack not reference-counted issues
143 These bugs typically present as use-after-free errors or as assertion
145 failures on the type of a "SV". Stack not reference-counted crashes
146 usually occur because code is both modifying a reference or glob and
147 using the values referenced by that glob or reference.
148 This type of bug is a long standing issue with the Perl interpreter
150 that seldom occurs in normal code. Examples of this type of bug
151 generally assume that attacker-supplied code will be evaluated by the
152 Perl interpreter.
153 Thawing attacker-supplied data with Storable
155 Storable is designed to be a very fast serialization format. It is not
157 designed to be safe for deserializing untrusted inputs.
158 Using attacker supplied SDBM_File databases
160 The SDBM_File module is not intended for use with untrusted SDBM
162 databases.
163 Badly encoded UTF-8 flagged scalars
165 This type of bug occurs when the ":utf8" PerlIO layer is used to read
167 badly encoded data, or other mechanisms are used to directly manipulate
168 the UTF-8 flag on an SV.
169 A badly encoded UTF-8 flagged SV is not a valid SV. Code that creates
171 SV's in this fashion is corrupting Perl's internal state.
172 Issues that exist only in blead, or in a release candidate
174 The blead branch and Perl release candidates do not receive security
176 support. Security defects that are present only in pre-release versions
177 of Perl are handled through the normal bug reporting and resolution
178 process.
179 CPAN modules or other Perl project resources
181 The Perl security team is focused on the Perl interpreter and modules
183 maintained in the core Perl codebase. The team has no special access to
184 fix CPAN modules, applications written in Perl, Perl project websites,
185 Perl mailing lists or the Perl IRC servers.
186 Emulated POSIX behaviors on Windows systems
188 The Perl interpreter attempts to emulate "fork", "system", "exec" and
190 other POSIX behaviors on Windows systems. This emulation has many
191 quirks that are extensively documented in Perl's public issue tracker.
192 Changing these behaviors would cause significant disruption for
193 existing users on Windows.
194 Bugs that require special categorization
196 Some bugs in the Perl interpreter occur in areas of the codebase that
197 are both security sensitive and prone to failure during normal usage.
198 Regular expressions
200 Untrusted regular expressions are generally safe to compile and match
202 against with several caveats. The following behaviors of Perl's regular
203 expression engine are the developer's responsibility to constrain.
204 The evaluation of untrusted regular expressions while "use re 'eval';"
206 is in effect is never safe.
207 Regular expressions are not guaranteed to compile or evaluate in any
209 specific finite time frame.
210 Regular expressions may consume all available system memory when they
212 are compiled or evaluated.
213 Regular expressions may cause excessive recursion that halts the perl
215 interpreter.
216 As a general rule, do not expect Perl's regular expression engine to be
218 resistant to denial of service attacks.
219 DB_File, ODBM_File, or GDBM_File databases
221 These modules rely on external libraries to interact with database
223 files.
224 Bugs caused by reading and writing these file formats are generally
226 caused by the underlying library implementation and are not security
227 issues in Perl.
228 Bugs where Perl mishandles unexpected valid return values from the
230 underlying libraries may qualify as security issues in Perl.
231 Algorithmic complexity attacks
233 The perl interpreter is reasonably robust to algorithmic complexity
235 attacks. It is not immune to them.
236 Algorithmic complexity bugs that depend on the interpreter processing
238 extremely large amounts of attacker supplied data are not generally
239 handled as security issues.
240 See "Algorithmic Complexity Attacks" in perlsec for additional
242 information.
243
245 The Perl security team follows responsible disclosure practices.
246 Security issues are kept secret until a fix is readily available for
247 most users. This minimizes inherent risks users face from
248 vulnerabilities in Perl.
249 Hiding problems from the users temporarily is a necessary trade-off to
251 keep them safe. Hiding problems from users permanently is not the goal.
252 When you report a security issue privately to the
254 perl-security@perl.org <mailto:perl-security@perl.org> contact address,
255 we normally expect you to follow responsible disclosure practices in
256 the handling of the report. If you are unable or unwilling to keep the
257 issue secret until a fix is available to users you should state this
258 clearly in the initial report.
259 The security team's vulnerability remediation workflow is intended to
261 be as open and transparent as possible about the state of your security
262 report.
263 Perl's vulnerability remediation workflow
265 Initial contact
266 New vulnerability reports will receive an initial reply within 72 hours
268 from the time they arrive at the security team's mailing list. If you
269 do not receive any response in that time, contact the Perl Steering
270 Council <mailto:steering-council@perl.org>.
271 The initial response sent by the security team will confirm your
273 message was received and provide an estimated time frame for the
274 security team's triage analysis.
275 Initial triage
277 The security team will evaluate the report and determine whether or not
279 it is likely to meet the criteria for handling as a security issue.
280 The security team aims to complete the initial report triage within two
282 weeks' time. Complex issues that require significant discussion or
283 research may take longer.
284 If the security report cannot be reproduced or does not meet the team's
286 criteria for handling as a security issue, you will be notified by
287 email and given an opportunity to respond.
288 Issue ID assignment
290 Security reports that pass initial triage analysis are turned into
292 issues in the security team's private issue tracker. When a report
293 progresses to this point you will be provided the issue ID for future
294 reference. These identifiers have the format perl-security#NNN or
295 Perl/perl-security#NNN.
296 The assignment of an issue ID does not confirm that a security report
298 represents a vulnerability in Perl. Many reports require further
299 analysis to reach that determination.
300 Issues in the security team's private tracker are used to collect
302 details about the problem and track progress towards a resolution.
303 These notes and other details are not made public when the issue is
304 resolved. Keeping the issue notes private allows the security team to
305 freely discuss attack methods, attack tools, and other related private
306 issues.
307 Development of patches
309 Members of the security team will inspect the report and related code
311 in detail to produce fixes for supported versions of Perl.
312 If the team discovers that the reported issue does not meet the team's
314 criteria at this stage, you will be notified by email and given an
315 opportunity to respond before the issue is closed.
316 The team may discuss potential fixes with you or provide you with
318 patches for testing purposes during this time frame. No information
319 should be shared publicly at this stage.
320 CVE ID assignment
322 Once an issue is fully confirmed and a potential fix has been found,
324 the security team will request a CVE identifier for the issue to use in
325 public announcements.
326 Details like the range of vulnerable Perl versions and identities of
328 the people that discovered the flaw need to be collected to submit the
329 CVE ID request.
330 The security team may ask you to clarify the exact name we should use
332 when crediting discovery of the issue. The "Vulnerability credit and
333 bounties" section of this document explains our preferred format for
334 this credit.
335 Once a CVE ID has been assigned, you will be notified by email. The
337 vulnerability should not be discussed publicly at this stage.
338 Pre-release notifications
340 When the security team is satisfied that the fix for a security issue
342 is ready to release publicly, a pre-release notification announcement
343 is sent to the major redistributors of Perl.
344 This pre-release announcement includes a list of Perl versions that are
346 affected by the flaw, an analysis of the risks to users, patches the
347 security team has produced, and any information about mitigations or
348 backporting fixes to older versions of Perl that the security team has
349 available.
350 The pre-release announcement will include a specific target date when
352 the issue will be announced publicly. The time frame between the pre-
353 release announcement and the release date allows redistributors to
354 prepare and test their own updates and announcements. During this
355 period the vulnerability details and fixes are embargoed and should not
356 be shared publicly. This embargo period may be extended further if
357 problems are discovered during testing.
358 You will be sent the portions of pre-release announcements that are
360 relevant to the specific issue you reported. This email will include
361 the target release date. Additional updates will be sent if the target
362 release date changes.
363 Pre-release testing
365 The Perl security team does not directly produce official Perl
367 releases. The team releases security fixes by placing commits in Perl's
368 public git repository and sending announcements.
369 Many users and redistributors prefer using official Perl releases
371 rather than applying patches to an older release. The security team
372 works with Perl's release managers to make this possible.
373 New official releases of Perl are generally produced and tested on
375 private systems during the pre-release embargo period.
376 Release of fixes and announcements
378 At the end of the embargo period the security fixes will be committed
380 to Perl's public git repository and announcements will be sent to the
381 perl5-porters <https://lists.perl.org/list/perl5-porters.html> and oss-
382 security <https://oss-security.openwall.org/wiki/mailing-lists/oss-
383 security> mailing lists.
384 If official Perl releases are ready, they will be published at this
386 time and announced on the perl5-porters
387 <https://lists.perl.org/list/perl5-porters.html> mailing list.
388 The security team will send a follow-up notification to everyone that
390 participated in the pre-release embargo period once the release process
391 is finished. Vulnerability reporters and Perl redistributors should not
392 publish their own announcements or fixes until the Perl security team's
393 release process is complete.
394 Publicly known and zero-day security issues
396 The security team's vulnerability remediation workflow assumes that
397 issues are reported privately and kept secret until they are resolved.
398 This isn't always the case and information occasionally leaks out
399 before a fix is ready.
400 In these situations the team must decide whether operating in secret
402 increases or decreases the risk to users of Perl. In some cases being
403 open about the risk a security issue creates will allow users to defend
404 against it, in other cases calling attention to an unresolved security
405 issue will make it more likely to be misused.
406 Zero-day security issues
408 If an unresolved critical security issue in Perl is being actively
410 abused to attack systems the security team will send out announcements
411 as rapidly as possible with any mitigations the team has available.
412 Perl's public defect tracker will be used to handle the issue so that
414 additional information, fixes, and CVE IDs are visible to affected
415 users as rapidly as possible.
416 Other leaks of security issue information
418 Depending on the prominence of the information revealed about a
420 security issue and the issue's risk of becoming a zero-day attack, the
421 security team may skip all or part of its normal remediation workflow.
422 If the security team learns of a significant security issue after it
424 has been identified and resolved in Perl's public issue tracker, the
425 team will request a CVE ID and send an announcement to inform users.
426 Vulnerability credit and bounties
428 The Perl project appreciates the effort security researchers invest in
429 making Perl safe and secure.
430 Since much of this work is hidden from the public, crediting
432 researchers publicly is an important part of the vulnerability
433 remediation process.
434 Credits in vulnerability announcements
436 When security issues are fixed we will attempt to credit the specific
438 researcher(s) that discovered the flaw in our announcements.
439 Credits are announced using the researcher's preferred full name.
441 If the researcher's contributions were funded by a specific company or
443 part of an organized vulnerability research project, we will include a
444 short name for this group at the researcher's request.
445 Perl's announcements are written in the English language using the 7bit
447 ASCII character set to be reproducible in a variety of formats. We do
448 not include hyperlinks, domain names or marketing material with these
449 acknowledgments.
450 In the event that proper credit for vulnerability discovery cannot be
452 established or there is a disagreement between the Perl security team
453 and the researcher about how the credit should be given, it will be
454 omitted from announcements.
455 Bounties for Perl vulnerabilities
457 The Perl project is a non-profit volunteer effort. We do not provide
459 any monetary rewards for reporting security issues in Perl.
460perl v5.38.2 2023-11-30 PERLSECPOLICY(1)