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