1PERLSECPOLICY(1)       Perl Programmers Reference Guide       PERLSECPOLICY(1)
2
3
4

NAME

6       perlsecpolicy - Perl security report handling policy
7

DESCRIPTION

9       The Perl project takes security issues seriously.
10
11       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
15       This document describes how the Perl security team operates and how the
16       team evaluates new security reports.
17

REPORTING SECURITY ISSUES IN PERL

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
25       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
29       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
36       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
41       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
46       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

WHAT ARE SECURITY ISSUES

53       A vulnerability is a behavior of a software system that compromises the
54       system's expected confidentiality, integrity or availability
55       protections.
56
57       A security issue is a bug in one or more specific components of a
58       software system that creates a vulnerability.
59
60       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
66   Software covered by the Perl security team
67       The Perl security team handles security issues in:
68
69       •   The Perl interpreter
70
71       •   The Perl modules shipped with the interpreter that are developed in
72           the core Perl repository
73
74       •   The command line tools shipped with the interpreter that are
75           developed in the core Perl repository
76
77       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
84   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
89       As a general rule, a bug in Perl needs to meet all of the following
90       criteria to be considered a security issue:
91
92       •   The vulnerable behavior is not mentioned in Perl's documentation or
93           public issue tracker.
94
95       •   The vulnerable behavior is not implied by an expected behavior.
96
97       •   The vulnerable behavior is not a generally accepted limitation of
98           the implementation.
99
100       •   The vulnerable behavior is likely to be exposed to attack in
101           otherwise secure applications written in Perl.
102
103       •   The vulnerable behavior provides a specific tangible benefit to an
104           attacker that triggers the behavior.
105
106   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
110       The following is a list of commonly reported bugs that are not handled
111       as security issues.
112
113       Feeding untrusted code to the interpreter
114
115       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
119       Stack overflows due to excessive recursion
120
121       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
125       Out of memory errors
126
127       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
133       Escape from a Safe compartment
134
135       Opcode restrictions and Safe compartments are not supported as security
136       mechanisms. The Perl parser is not designed to evaluate untrusted code.
137
138       Use of the "p" and "P" pack templates
139
140       These templates are unsafe by design.
141
142       Stack not reference-counted issues
143
144       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
149       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
154       Thawing attacker-supplied data with Storable
155
156       Storable is designed to be a very fast serialization format.  It is not
157       designed to be safe for deserializing untrusted inputs.
158
159       Using attacker supplied SDBM_File databases
160
161       The SDBM_File module is not intended for use with untrusted SDBM
162       databases.
163
164       Badly encoded UTF-8 flagged scalars
165
166       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
170       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
173       Issues that exist only in blead, or in a release candidate
174
175       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
180       CPAN modules or other Perl project resources
181
182       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
187       Emulated POSIX behaviors on Windows systems
188
189       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
195   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
199       Regular expressions
200
201       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
205       The evaluation of untrusted regular expressions while "use re 'eval';"
206       is in effect is never safe.
207
208       Regular expressions are not guaranteed to compile or evaluate in any
209       specific finite time frame.
210
211       Regular expressions may consume all available system memory when they
212       are compiled or evaluated.
213
214       Regular expressions may cause excessive recursion that halts the perl
215       interpreter.
216
217       As a general rule, do not expect Perl's regular expression engine to be
218       resistant to denial of service attacks.
219
220       DB_File, ODBM_File, or GDBM_File databases
221
222       These modules rely on external libraries to interact with database
223       files.
224
225       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
229       Bugs where Perl mishandles unexpected valid return values from the
230       underlying libraries may qualify as security issues in Perl.
231
232       Algorithmic complexity attacks
233
234       The perl interpreter is reasonably robust to algorithmic complexity
235       attacks. It is not immune to them.
236
237       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
241       See "Algorithmic Complexity Attacks" in perlsec for additional
242       information.
243

HOW WE DEAL WITH SECURITY ISSUES

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
250       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
253       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
260       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
264   Perl's vulnerability remediation workflow
265       Initial contact
266
267       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
272       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
276       Initial triage
277
278       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
281       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
285       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
289       Issue ID assignment
290
291       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
297       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
301       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
308       Development of patches
309
310       Members of the security team will inspect the report and related code
311       in detail to produce fixes for supported versions of Perl.
312
313       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
317       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
321       CVE ID assignment
322
323       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
327       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
331       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
336       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
339       Pre-release notifications
340
341       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
345       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
351       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
359       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
364       Pre-release testing
365
366       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
370       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
374       New official releases of Perl are generally produced and tested on
375       private systems during the pre-release embargo period.
376
377       Release of fixes and announcements
378
379       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
385       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
389       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
395   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
401       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
407       Zero-day security issues
408
409       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
413       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
417       Other leaks of security issue information
418
419       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
423       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
427   Vulnerability credit and bounties
428       The Perl project appreciates the effort security researchers invest in
429       making Perl safe and secure.
430
431       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
435       Credits in vulnerability announcements
436
437       When security issues are fixed we will attempt to credit the specific
438       researcher(s) that discovered the flaw in our announcements.
439
440       Credits are announced using the researcher's preferred full name.
441
442       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
446       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
451       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
456       Bounties for Perl vulnerabilities
457
458       The Perl project is a non-profit volunteer effort. We do not provide
459       any monetary rewards for reporting security issues in Perl.
460
461
462
463perl v5.38.2                      2023-11-30                  PERLSECPOLICY(1)
Impressum