4 CVE perlsecpolicy SV perl Perl SDBM HackerOne Mitre
8 perlsecpolicy - Perl security report handling policy
12 The Perl project takes security issues seriously.
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.
18 This document describes how the Perl security team operates and
19 how the team evaluates new security reports.
21 =head1 REPORTING SECURITY ISSUES IN PERL
23 If you believe you have found a security vulnerability in the Perl
24 interpreter or modules maintained in the core Perl codebase,
26 L<perl-security@perl.org|mailto:perl-security@perl.org>.
27 This address is a closed membership mailing list monitored by the Perl
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
32 the security team lead L<John Lightsey|mailto:john@04755.net> and
33 the Perl pumpking L<SawyerX|mailto:xsawyerx@cpan.org>.
35 When members of the security team reply to your messages, they will
36 generally include the perl-security@perl.org address in the "To" or "CC"
37 fields of the response. This allows all of the security team to follow
38 the discussion and chime in as needed. Use the "Reply-all" functionality
39 of your email client when you send subsequent responses so that the
40 entire security team receives the message.
42 The security team will evaluate your report and make an initial
43 determination of whether it is likely to fit the scope of issues the
44 team handles. General guidelines about how this is determined are
45 detailed in the L</WHAT ARE SECURITY ISSUES> section.
47 If your report meets the team's criteria, an issue will be opened in the
48 team's private issue tracker and you will be provided the issue's ID number.
49 Issue identifiers have the form perl-security#NNN. Include this identifier
50 with any subsequent messages you send.
52 The security team will send periodic updates about the status of your
53 issue and guide you through any further action that is required to complete
54 the vulnerability remediation process. The stages vulnerabilities typically
55 go through are explained in the L</HOW WE DEAL WITH SECURITY ISSUES>
58 =head1 WHAT ARE SECURITY ISSUES
60 A vulnerability is a behavior of a software system that compromises the
61 system's expected confidentiality, integrity or availability protections.
63 A security issue is a bug in one or more specific components of a software
64 system that creates a vulnerability.
66 Software written in the Perl programming language is typically composed
67 of many layers of software written by many different groups. It can be
68 very complicated to determine which specific layer of a complex real-world
69 application was responsible for preventing a vulnerable behavior, but this
70 is an essential part of fixing the vulnerability.
72 =head2 Software covered by the Perl security team
74 The Perl security team handles security issues in:
84 The Perl modules shipped with the interpreter that are developed in the core
89 The command line tools shipped with the interpreter that are developed in the
94 Files under the F<cpan/> directory in Perl's repository and release tarballs are
95 developed and maintained independently. The Perl security team does not handle
96 security issues for these modules.
98 =head2 Bugs that may qualify as security issues in Perl
100 Perl is designed to be a fast and flexible general purpose programming
101 language. The Perl interpreter and Perl modules make writing safe and
102 secure applications easy, but they do have limitations.
104 As a general rule, a bug in Perl needs to meet all of the following
105 criteria to be considered a security issue:
111 The vulnerable behavior is not mentioned in Perl's documentation
112 or public issue tracker.
116 The vulnerable behavior is not implied by an expected behavior.
120 The vulnerable behavior is not a generally accepted limitation of
125 The vulnerable behavior is likely to be exposed to attack in
126 otherwise secure applications written in Perl.
130 The vulnerable behavior provides a specific tangible benefit
131 to an attacker that triggers the behavior.
135 =head2 Bugs that do not qualify as security issues in Perl
137 There are certain categories of bugs that are frequently reported to
138 the security team that do not meet the criteria listed above.
140 The following is a list of commonly reported bugs that are not
141 handled as security issues.
143 =head3 Feeding untrusted code to the interpreter
145 The Perl parser is not designed to evaluate untrusted code.
146 If your application requires the evaluation of untrusted code, it
147 should rely on an operating system level sandbox for its security.
149 =head3 Stack overflows due to excessive recursion
151 Excessive recursion is often caused by code that does
152 not enforce limits on inputs. The Perl interpreter assumes limits
153 on recursion will be enforced by the application.
155 =head3 Out of memory errors
157 Common Perl constructs such as C<pack>, the C<x> operator,
158 and regular expressions accept numeric quantifiers that control how
159 much memory will be allocated to store intermediate values or results.
160 If you allow an attacker to supply these quantifiers and consume all
161 available memory, the Perl interpreter will not prevent it.
163 =head3 Escape from a L<Safe> compartment
165 L<Opcode> restrictions and L<Safe> compartments are not supported as
166 security mechanisms. The Perl parser is not designed to evaluate
169 =head3 Use of the C<p> and C<P> pack templates
171 These templates are unsafe by design.
173 =head3 Stack not reference-counted issues
175 These bugs typically present as use-after-free errors or as assertion
176 failures on the type of a C<SV>. Stack not reference-counted
177 crashes usually occur because code is both modifying a reference or
178 glob and using the values referenced by that glob or reference.
180 This type of bug is a long standing issue with the Perl interpreter
181 that seldom occurs in normal code. Examples of this type of bug
182 generally assume that attacker-supplied code will be evaluated by
183 the Perl interpreter.
185 =head3 Thawing attacker-supplied data with L<Storable>
187 L<Storable> is designed to be a very fast serialization format.
188 It is not designed to be safe for deserializing untrusted inputs.
190 =head3 Using attacker supplied L<SDBM_File> databases
192 The L<SDBM_File> module is not intended for use with untrusted SDBM
195 =head3 Badly encoded UTF-8 flagged scalars
197 This type of bug occurs when the C<:utf8> PerlIO layer is used to
198 read badly encoded data, or other mechanisms are used to directly
199 manipulate the UTF-8 flag on an SV.
201 A badly encoded UTF-8 flagged SV is not a valid SV. Code that
202 creates SV's in this fashion is corrupting Perl's internal state.
204 =head3 Issues that exist only in blead, or in a release candidate
206 The blead branch and Perl release candidates do not receive security
207 support. Security defects that are present only in pre-release
208 versions of Perl are handled through the normal bug reporting and
211 =head3 CPAN modules or other Perl project resources
213 The Perl security team is focused on the Perl interpreter and modules
214 maintained in the core Perl codebase. The team has no special access
215 to fix CPAN modules, applications written in Perl, Perl project websites,
216 Perl mailing lists or the Perl IRC servers.
218 =head3 Emulated POSIX behaviors on Windows systems
220 The Perl interpreter attempts to emulate C<fork>, C<system>, C<exec>
221 and other POSIX behaviors on Windows systems. This emulation has many
222 quirks that are extensively documented in Perl's public issue tracker.
223 Changing these behaviors would cause significant disruption for existing
226 =head2 Bugs that require special categorization
228 Some bugs in the Perl interpreter occur in areas of the codebase that are
229 both security sensitive and prone to failure during normal usage.
231 =head3 Regular expressions
233 Untrusted regular expressions are generally safe to compile and match against
234 with several caveats. The following behaviors of Perl's regular expression
235 engine are the developer's responsibility to constrain.
237 The evaluation of untrusted regular expressions while C<use re 'eval';> is
238 in effect is never safe.
240 Regular expressions are not guaranteed to compile or evaluate in any specific
243 Regular expressions may consume all available system memory when they are
244 compiled or evaluated.
246 Regular expressions may cause excessive recursion that halts the perl
249 As a general rule, do not expect Perl's regular expression engine to
250 be resistant to denial of service attacks.
252 =head3 L<DB_File>, L<ODBM_File>, or L<GDBM_File> databases
254 These modules rely on external libraries to interact with database files.
256 Bugs caused by reading and writing these file formats are generally caused
257 by the underlying library implementation and are not security issues in
260 Bugs where Perl mishandles unexpected valid return values from the underlying
261 libraries may qualify as security issues in Perl.
263 =head3 Algorithmic complexity attacks
265 The perl interpreter is reasonably robust to algorithmic complexity
266 attacks. It is not immune to them.
268 Algorithmic complexity bugs that depend on the interpreter processing
269 extremely large amounts of attacker supplied data are not generally handled
272 See L<perlsec/Algorithmic Complexity Attacks> for additional information.
274 =head1 HOW WE DEAL WITH SECURITY ISSUES
276 The Perl security team follows responsible disclosure practices. Security issues
277 are kept secret until a fix is readily available for most users. This minimizes
278 inherent risks users face from vulnerabilities in Perl.
280 Hiding problems from the users temporarily is a necessary trade-off to keep
281 them safe. Hiding problems from users permanently is not the goal.
283 When you report a security issue privately to the
284 L<perl-security@perl.org|mailto:perl-security@perl.org> contact address, we
285 normally expect you to follow responsible disclosure practices in the handling
286 of the report. If you are unable or unwilling to keep the issue secret until
287 a fix is available to users you should state this clearly in the initial
290 The security team's vulnerability remediation workflow is intended to be as
291 open and transparent as possible about the state of your security report.
293 =head2 Perl's vulnerability remediation workflow
295 =head3 Initial contact
297 New vulnerability reports will receive an initial reply within 72 hours
298 from the time they arrive at the security team's mailing list. If you do
299 not receive any response in that time, contact the security team lead
300 L<John Lightsey|mailto:john@04755.net> and the Perl pumpking
301 L<SawyerX|mailto:xsawyerx@cpan.org>.
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
307 =head3 Initial triage
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.
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.
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.
320 =head3 Issue ID assignment
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.
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.
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.
337 =head3 Development of patches
339 Members of the security team will inspect the report and related code in
340 detail to produce fixes for supported versions of Perl.
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.
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.
350 =head3 CVE ID assignment
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.
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
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.
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.
368 =head3 Pre-release notifications
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.
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
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.
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.
393 =head3 Pre-release testing
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.
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.
403 New official releases of Perl are generally produced and tested
404 on private systems during the pre-release embargo period.
406 =head3 Release of fixes and announcements
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>
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>
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
424 =head2 Publicly known and zero-day security issues
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.
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.
436 =head3 Zero-day security issues
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.
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
446 =head3 Other leaks of security issue information
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.
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.
456 =head2 Vulnerability credit and bounties
458 The Perl project appreciates the effort security researchers
459 invest in making Perl safe and secure.
461 Since much of this work is hidden from the public, crediting
462 researchers publicly is an important part of the vulnerability
465 =head3 Credits in vulnerability announcements
467 When security issues are fixed we will attempt to credit the specific
468 researcher(s) that discovered the flaw in our announcements.
470 Credits are announced using the researcher's preferred full name.
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.
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
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.
486 =head3 Bounties for Perl vulnerabilities
488 The Perl project is a non-profit volunteer effort. We do not provide
489 any monetary rewards for reporting security issues in Perl.
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>.
495 This program is not run by the Perl project or the Perl security team.