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 L<Perl Steering Council|mailto:steering-council@perl.org>. 33 34When members of the security team reply to your messages, they will 35generally include the perl-security@perl.org address in the "To" or "CC" 36fields of the response. This allows all of the security team to follow 37the discussion and chime in as needed. Use the "Reply-all" functionality 38of your email client when you send subsequent responses so that the 39entire security team receives the message. 40 41The security team will evaluate your report and make an initial 42determination of whether it is likely to fit the scope of issues the 43team handles. General guidelines about how this is determined are 44detailed in the L</WHAT ARE SECURITY ISSUES> section. 45 46If your report meets the team's criteria, an issue will be opened in the 47team's private issue tracker and you will be provided the issue's ID number. 48Issue identifiers have the form perl-security#NNN. Include this identifier 49with any subsequent messages you send. 50 51The security team will send periodic updates about the status of your 52issue and guide you through any further action that is required to complete 53the vulnerability remediation process. The stages vulnerabilities typically 54go through are explained in the L</HOW WE DEAL WITH SECURITY ISSUES> 55section. 56 57=head1 WHAT ARE SECURITY ISSUES 58 59A vulnerability is a behavior of a software system that compromises the 60system's expected confidentiality, integrity or availability protections. 61 62A security issue is a bug in one or more specific components of a software 63system that creates a vulnerability. 64 65Software written in the Perl programming language is typically composed 66of many layers of software written by many different groups. It can be 67very complicated to determine which specific layer of a complex real-world 68application was responsible for preventing a vulnerable behavior, but this 69is an essential part of fixing the vulnerability. 70 71=head2 Software covered by the Perl security team 72 73The Perl security team handles security issues in: 74 75=over 76 77=item * 78 79The Perl interpreter 80 81=item * 82 83The Perl modules shipped with the interpreter that are developed in the core 84Perl repository 85 86=item * 87 88The command line tools shipped with the interpreter that are developed in the 89core Perl repository 90 91=back 92 93Files under the F<cpan/> directory in Perl's repository and release tarballs are 94developed and maintained independently. The Perl security team does not 95directly handle security issues for these modules, but since this code is 96bundled with Perl, we will assist in forwarding the issue to the relevant 97maintainer(s) and you can still report these issues to us in secrecy. 98 99=head2 Bugs that may qualify as security issues in Perl 100 101Perl is designed to be a fast and flexible general purpose programming 102language. The Perl interpreter and Perl modules make writing safe and 103secure applications easy, but they do have limitations. 104 105As a general rule, a bug in Perl needs to meet all of the following 106criteria to be considered a security issue: 107 108=over 109 110=item * 111 112The vulnerable behavior is not mentioned in Perl's documentation 113or public issue tracker. 114 115=item * 116 117The vulnerable behavior is not implied by an expected behavior. 118 119=item * 120 121The vulnerable behavior is not a generally accepted limitation of 122the implementation. 123 124=item * 125 126The vulnerable behavior is likely to be exposed to attack in 127otherwise secure applications written in Perl. 128 129=item * 130 131The vulnerable behavior provides a specific tangible benefit 132to an attacker that triggers the behavior. 133 134=back 135 136=head2 Bugs that do not qualify as security issues in Perl 137 138There are certain categories of bugs that are frequently reported to 139the security team that do not meet the criteria listed above. 140 141The following is a list of commonly reported bugs that are not 142handled as security issues. 143 144=head3 Feeding untrusted code to the interpreter 145 146The Perl parser is not designed to evaluate untrusted code. 147If your application requires the evaluation of untrusted code, it 148should rely on an operating system level sandbox for its security. 149 150=head3 Stack overflows due to excessive recursion 151 152Excessive recursion is often caused by code that does 153not enforce limits on inputs. The Perl interpreter assumes limits 154on recursion will be enforced by the application. 155 156=head3 Out of memory errors 157 158Common Perl constructs such as C<pack>, the C<x> operator, 159and regular expressions accept numeric quantifiers that control how 160much memory will be allocated to store intermediate values or results. 161If you allow an attacker to supply these quantifiers and consume all 162available memory, the Perl interpreter will not prevent it. 163 164=head3 Escape from a L<Safe> compartment 165 166L<Opcode> restrictions and L<Safe> compartments are not supported as 167security mechanisms. The Perl parser is not designed to evaluate 168untrusted code. 169 170=head3 Use of the C<p> and C<P> pack templates 171 172These templates are unsafe by design. 173 174=head3 Stack not reference-counted issues 175 176These bugs typically present as use-after-free errors or as assertion 177failures on the type of a C<SV>. Stack not reference-counted 178crashes usually occur because code is both modifying a reference or 179glob and using the values referenced by that glob or reference. 180 181This type of bug is a long standing issue with the Perl interpreter 182that seldom occurs in normal code. Examples of this type of bug 183generally assume that attacker-supplied code will be evaluated by 184the Perl interpreter. 185 186=head3 Thawing attacker-supplied data with L<Storable> 187 188L<Storable> is designed to be a very fast serialization format. 189It is not designed to be safe for deserializing untrusted inputs. 190 191=head3 Using attacker supplied L<SDBM_File> databases 192 193The L<SDBM_File> module is not intended for use with untrusted SDBM 194databases. 195 196=head3 Badly encoded UTF-8 flagged scalars 197 198This type of bug occurs when the C<:utf8> PerlIO layer is used to 199read badly encoded data, or other mechanisms are used to directly 200manipulate the UTF-8 flag on an SV. 201 202A badly encoded UTF-8 flagged SV is not a valid SV. Code that 203creates SV's in this fashion is corrupting Perl's internal state. 204 205=head3 Issues that exist only in blead, or in a release candidate 206 207The blead branch and Perl release candidates do not receive security 208support. Security defects that are present only in pre-release 209versions of Perl are handled through the normal bug reporting and 210resolution process. 211 212=head3 CPAN modules or other Perl project resources 213 214The Perl security team is focused on the Perl interpreter and modules 215maintained in the core Perl codebase. The team has no special access 216to fix CPAN modules, applications written in Perl, Perl project websites, 217Perl mailing lists or the Perl IRC servers. 218 219=head3 Emulated POSIX behaviors on Windows systems 220 221The Perl interpreter attempts to emulate C<fork>, C<system>, C<exec> 222and other POSIX behaviors on Windows systems. This emulation has many 223quirks that are extensively documented in Perl's public issue tracker. 224Changing these behaviors would cause significant disruption for existing 225users on Windows. 226 227=head2 Bugs that require special categorization 228 229Some bugs in the Perl interpreter occur in areas of the codebase that are 230both security sensitive and prone to failure during normal usage. 231 232=head3 Regular expressions 233 234Untrusted regular expressions are generally safe to compile and match against 235with several caveats. The following behaviors of Perl's regular expression 236engine are the developer's responsibility to constrain. 237 238The evaluation of untrusted regular expressions while C<use re 'eval';> is 239in effect is never safe. 240 241Regular expressions are not guaranteed to compile or evaluate in any specific 242finite time frame. 243 244Regular expressions may consume all available system memory when they are 245compiled or evaluated. 246 247Regular expressions may cause excessive recursion that halts the perl 248interpreter. 249 250As a general rule, do not expect Perl's regular expression engine to 251be resistant to denial of service attacks. 252 253=head3 L<DB_File>, L<ODBM_File>, or L<GDBM_File> databases 254 255These modules rely on external libraries to interact with database files. 256 257Bugs caused by reading and writing these file formats are generally caused 258by the underlying library implementation and are not security issues in 259Perl. 260 261Bugs where Perl mishandles unexpected valid return values from the underlying 262libraries may qualify as security issues in Perl. 263 264=head3 Algorithmic complexity attacks 265 266The perl interpreter is reasonably robust to algorithmic complexity 267attacks. It is not immune to them. 268 269Algorithmic complexity bugs that depend on the interpreter processing 270extremely large amounts of attacker supplied data are not generally handled 271as security issues. 272 273See L<perlsec/Algorithmic Complexity Attacks> for additional information. 274 275=head1 HOW WE DEAL WITH SECURITY ISSUES 276 277The Perl security team follows responsible disclosure practices. Security issues 278are kept secret until a fix is readily available for most users. This minimizes 279inherent risks users face from vulnerabilities in Perl. 280 281Hiding problems from the users temporarily is a necessary trade-off to keep 282them safe. Hiding problems from users permanently is not the goal. 283 284When you report a security issue privately to the 285L<perl-security@perl.org|mailto:perl-security@perl.org> contact address, we 286normally expect you to follow responsible disclosure practices in the handling 287of the report. If you are unable or unwilling to keep the issue secret until 288a fix is available to users you should state this clearly in the initial 289report. 290 291The security team's vulnerability remediation workflow is intended to be as 292open and transparent as possible about the state of your security report. 293 294=head2 Perl's vulnerability remediation workflow 295 296=head3 Initial contact 297 298New vulnerability reports will receive an initial reply within 72 hours 299from the time they arrive at the security team's mailing list. If you do 300not receive any response in that time, contact the 301L<Perl Steering Council|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 491=cut 492