diff options
Diffstat (limited to 'upstream/mageia-cauldron/man1/perlsecpolicy.1')
| -rw-r--r-- | upstream/mageia-cauldron/man1/perlsecpolicy.1 | 537 |
1 files changed, 537 insertions, 0 deletions
diff --git a/upstream/mageia-cauldron/man1/perlsecpolicy.1 b/upstream/mageia-cauldron/man1/perlsecpolicy.1 new file mode 100644 index 00000000..cf3a8ecf --- /dev/null +++ b/upstream/mageia-cauldron/man1/perlsecpolicy.1 @@ -0,0 +1,537 @@ +.\" -*- mode: troff; coding: utf-8 -*- +.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43) +.\" +.\" Standard preamble: +.\" ======================================================================== +.de Sp \" Vertical space (when we can't use .PP) +.if t .sp .5v +.if n .sp +.. +.de Vb \" Begin verbatim text +.ft CW +.nf +.ne \\$1 +.. +.de Ve \" End verbatim text +.ft R +.fi +.. +.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>. +.ie n \{\ +. ds C` "" +. ds C' "" +'br\} +.el\{\ +. ds C` +. ds C' +'br\} +.\" +.\" Escape single quotes in literal strings from groff's Unicode transform. +.ie \n(.g .ds Aq \(aq +.el .ds Aq ' +.\" +.\" If the F register is >0, we'll generate index entries on stderr for +.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index +.\" entries marked with X<> in POD. Of course, you'll have to process the +.\" output yourself in some meaningful fashion. +.\" +.\" Avoid warning from groff about undefined register 'F'. +.de IX +.. +.nr rF 0 +.if \n(.g .if rF .nr rF 1 +.if (\n(rF:(\n(.g==0)) \{\ +. if \nF \{\ +. de IX +. tm Index:\\$1\t\\n%\t"\\$2" +.. +. if !\nF==2 \{\ +. nr % 0 +. nr F 2 +. \} +. \} +.\} +.rr rF +.\" ======================================================================== +.\" +.IX Title "PERLSECPOLICY 1" +.TH PERLSECPOLICY 1 2023-11-28 "perl v5.38.2" "Perl Programmers Reference Guide" +.\" For nroff, turn off justification. Always turn off hyphenation; it makes +.\" way too many mistakes in technical documents. +.if n .ad l +.nh +.SH NAME +perlsecpolicy \- Perl security report handling policy +.SH DESCRIPTION +.IX Header "DESCRIPTION" +The Perl project takes security issues seriously. +.PP +The responsibility for handling security reports in a timely and +effective manner has been delegated to a security team composed +of a subset of the Perl core developers. +.PP +This document describes how the Perl security team operates and +how the team evaluates new security reports. +.SH "REPORTING SECURITY ISSUES IN PERL" +.IX Header "REPORTING SECURITY ISSUES IN PERL" +If you believe you have found a security vulnerability in the Perl +interpreter or modules maintained in the core Perl codebase, +email the details to +perl\-security@perl.org <mailto:perl-security@perl.org>. +This address is a closed membership mailing list monitored by the Perl +security team. +.PP +You should receive an initial response to your report within 72 hours. +If you do not receive a response in that time, please contact +the Perl Steering Council <mailto:steering-council@perl.org>. +.PP +When members of the security team reply to your messages, they will +generally include the perl\-security@perl.org address in the "To" or "CC" +fields of the response. This allows all of the security team to follow +the discussion and chime in as needed. Use the "Reply-all" functionality +of your email client when you send subsequent responses so that the +entire security team receives the message. +.PP +The security team will evaluate your report and make an initial +determination of whether it is likely to fit the scope of issues the +team handles. General guidelines about how this is determined are +detailed in the "WHAT ARE SECURITY ISSUES" section. +.PP +If your report meets the team's criteria, an issue will be opened in the +team's private issue tracker and you will be provided the issue's ID number. +Issue identifiers have the form perl\-security#NNN. Include this identifier +with any subsequent messages you send. +.PP +The security team will send periodic updates about the status of your +issue and guide you through any further action that is required to complete +the vulnerability remediation process. The stages vulnerabilities typically +go through are explained in the "HOW WE DEAL WITH SECURITY ISSUES" +section. +.SH "WHAT ARE SECURITY ISSUES" +.IX Header "WHAT ARE SECURITY ISSUES" +A vulnerability is a behavior of a software system that compromises the +system's expected confidentiality, integrity or availability protections. +.PP +A security issue is a bug in one or more specific components of a software +system that creates a vulnerability. +.PP +Software written in the Perl programming language is typically composed +of many layers of software written by many different groups. It can be +very complicated to determine which specific layer of a complex real-world +application was responsible for preventing a vulnerable behavior, but this +is an essential part of fixing the vulnerability. +.SS "Software covered by the Perl security team" +.IX Subsection "Software covered by the Perl security team" +The Perl security team handles security issues in: +.IP \(bu 4 +The Perl interpreter +.IP \(bu 4 +The Perl modules shipped with the interpreter that are developed in the core +Perl repository +.IP \(bu 4 +The command line tools shipped with the interpreter that are developed in the +core Perl repository +.PP +Files under the \fIcpan/\fR directory in Perl's repository and release tarballs are +developed and maintained independently. The Perl security team does not +directly handle security issues for these modules, but since this code is +bundled with Perl, we will assist in forwarding the issue to the relevant +maintainer(s) and you can still report these issues to us in secrecy. +.SS "Bugs that may qualify as security issues in Perl" +.IX Subsection "Bugs that may qualify as security issues in Perl" +Perl is designed to be a fast and flexible general purpose programming +language. The Perl interpreter and Perl modules make writing safe and +secure applications easy, but they do have limitations. +.PP +As a general rule, a bug in Perl needs to meet all of the following +criteria to be considered a security issue: +.IP \(bu 4 +The vulnerable behavior is not mentioned in Perl's documentation +or public issue tracker. +.IP \(bu 4 +The vulnerable behavior is not implied by an expected behavior. +.IP \(bu 4 +The vulnerable behavior is not a generally accepted limitation of +the implementation. +.IP \(bu 4 +The vulnerable behavior is likely to be exposed to attack in +otherwise secure applications written in Perl. +.IP \(bu 4 +The vulnerable behavior provides a specific tangible benefit +to an attacker that triggers the behavior. +.SS "Bugs that do not qualify as security issues in Perl" +.IX Subsection "Bugs that do not qualify as security issues in Perl" +There are certain categories of bugs that are frequently reported to +the security team that do not meet the criteria listed above. +.PP +The following is a list of commonly reported bugs that are not +handled as security issues. +.PP +\fIFeeding untrusted code to the interpreter\fR +.IX Subsection "Feeding untrusted code to the interpreter" +.PP +The Perl parser is not designed to evaluate untrusted code. +If your application requires the evaluation of untrusted code, it +should rely on an operating system level sandbox for its security. +.PP +\fIStack overflows due to excessive recursion\fR +.IX Subsection "Stack overflows due to excessive recursion" +.PP +Excessive recursion is often caused by code that does +not enforce limits on inputs. The Perl interpreter assumes limits +on recursion will be enforced by the application. +.PP +\fIOut of memory errors\fR +.IX Subsection "Out of memory errors" +.PP +Common Perl constructs such as \f(CW\*(C`pack\*(C'\fR, the \f(CW\*(C`x\*(C'\fR operator, +and regular expressions accept numeric quantifiers that control how +much memory will be allocated to store intermediate values or results. +If you allow an attacker to supply these quantifiers and consume all +available memory, the Perl interpreter will not prevent it. +.PP +\fIEscape from a Safe compartment\fR +.IX Subsection "Escape from a Safe compartment" +.PP +Opcode restrictions and Safe compartments are not supported as +security mechanisms. The Perl parser is not designed to evaluate +untrusted code. +.PP +\fIUse of the \fR\f(CI\*(C`p\*(C'\fR\fI and \fR\f(CI\*(C`P\*(C'\fR\fI pack templates\fR +.IX Subsection "Use of the p and P pack templates" +.PP +These templates are unsafe by design. +.PP +\fIStack not reference-counted issues\fR +.IX Subsection "Stack not reference-counted issues" +.PP +These bugs typically present as use-after-free errors or as assertion +failures on the type of a \f(CW\*(C`SV\*(C'\fR. Stack not reference-counted +crashes usually occur because code is both modifying a reference or +glob and using the values referenced by that glob or reference. +.PP +This type of bug is a long standing issue with the Perl interpreter +that seldom occurs in normal code. Examples of this type of bug +generally assume that attacker-supplied code will be evaluated by +the Perl interpreter. +.PP +\fIThawing attacker-supplied data with Storable\fR +.IX Subsection "Thawing attacker-supplied data with Storable" +.PP +Storable is designed to be a very fast serialization format. +It is not designed to be safe for deserializing untrusted inputs. +.PP +\fIUsing attacker supplied SDBM_File databases\fR +.IX Subsection "Using attacker supplied SDBM_File databases" +.PP +The SDBM_File module is not intended for use with untrusted SDBM +databases. +.PP +\fIBadly encoded UTF\-8 flagged scalars\fR +.IX Subsection "Badly encoded UTF-8 flagged scalars" +.PP +This type of bug occurs when the \f(CW\*(C`:utf8\*(C'\fR PerlIO layer is used to +read badly encoded data, or other mechanisms are used to directly +manipulate the UTF\-8 flag on an SV. +.PP +A badly encoded UTF\-8 flagged SV is not a valid SV. Code that +creates SV's in this fashion is corrupting Perl's internal state. +.PP +\fIIssues that exist only in blead, or in a release candidate\fR +.IX Subsection "Issues that exist only in blead, or in a release candidate" +.PP +The blead branch and Perl release candidates do not receive security +support. Security defects that are present only in pre-release +versions of Perl are handled through the normal bug reporting and +resolution process. +.PP +\fICPAN modules or other Perl project resources\fR +.IX Subsection "CPAN modules or other Perl project resources" +.PP +The Perl security team is focused on the Perl interpreter and modules +maintained in the core Perl codebase. The team has no special access +to fix CPAN modules, applications written in Perl, Perl project websites, +Perl mailing lists or the Perl IRC servers. +.PP +\fIEmulated POSIX behaviors on Windows systems\fR +.IX Subsection "Emulated POSIX behaviors on Windows systems" +.PP +The Perl interpreter attempts to emulate \f(CW\*(C`fork\*(C'\fR, \f(CW\*(C`system\*(C'\fR, \f(CW\*(C`exec\*(C'\fR +and other POSIX behaviors on Windows systems. This emulation has many +quirks that are extensively documented in Perl's public issue tracker. +Changing these behaviors would cause significant disruption for existing +users on Windows. +.SS "Bugs that require special categorization" +.IX Subsection "Bugs that require special categorization" +Some bugs in the Perl interpreter occur in areas of the codebase that are +both security sensitive and prone to failure during normal usage. +.PP +\fIRegular expressions\fR +.IX Subsection "Regular expressions" +.PP +Untrusted regular expressions are generally safe to compile and match against +with several caveats. The following behaviors of Perl's regular expression +engine are the developer's responsibility to constrain. +.PP +The evaluation of untrusted regular expressions while \f(CW\*(C`use re \*(Aqeval\*(Aq;\*(C'\fR is +in effect is never safe. +.PP +Regular expressions are not guaranteed to compile or evaluate in any specific +finite time frame. +.PP +Regular expressions may consume all available system memory when they are +compiled or evaluated. +.PP +Regular expressions may cause excessive recursion that halts the perl +interpreter. +.PP +As a general rule, do not expect Perl's regular expression engine to +be resistant to denial of service attacks. +.PP +\fIDB_File, ODBM_File, or GDBM_File databases\fR +.IX Subsection "DB_File, ODBM_File, or GDBM_File databases" +.PP +These modules rely on external libraries to interact with database files. +.PP +Bugs caused by reading and writing these file formats are generally caused +by the underlying library implementation and are not security issues in +Perl. +.PP +Bugs where Perl mishandles unexpected valid return values from the underlying +libraries may qualify as security issues in Perl. +.PP +\fIAlgorithmic complexity attacks\fR +.IX Subsection "Algorithmic complexity attacks" +.PP +The perl interpreter is reasonably robust to algorithmic complexity +attacks. It is not immune to them. +.PP +Algorithmic complexity bugs that depend on the interpreter processing +extremely large amounts of attacker supplied data are not generally handled +as security issues. +.PP +See "Algorithmic Complexity Attacks" in perlsec for additional information. +.SH "HOW WE DEAL WITH SECURITY ISSUES" +.IX Header "HOW WE DEAL WITH SECURITY ISSUES" +The Perl security team follows responsible disclosure practices. Security issues +are kept secret until a fix is readily available for most users. This minimizes +inherent risks users face from vulnerabilities in Perl. +.PP +Hiding problems from the users temporarily is a necessary trade-off to keep +them safe. Hiding problems from users permanently is not the goal. +.PP +When you report a security issue privately to the +perl\-security@perl.org <mailto:perl-security@perl.org> contact address, we +normally expect you to follow responsible disclosure practices in the handling +of the report. If you are unable or unwilling to keep the issue secret until +a fix is available to users you should state this clearly in the initial +report. +.PP +The security team's vulnerability remediation workflow is intended to be as +open and transparent as possible about the state of your security report. +.SS "Perl's vulnerability remediation workflow" +.IX Subsection "Perl's vulnerability remediation workflow" +\fIInitial contact\fR +.IX Subsection "Initial contact" +.PP +New vulnerability reports will receive an initial reply within 72 hours +from the time they arrive at the security team's mailing list. If you do +not receive any response in that time, contact the +Perl Steering Council <mailto:steering-council@perl.org>. +.PP +The initial response sent by the security team will confirm your message was +received and provide an estimated time frame for the security team's +triage analysis. +.PP +\fIInitial triage\fR +.IX Subsection "Initial triage" +.PP +The security team will evaluate the report and determine whether or not +it is likely to meet the criteria for handling as a security issue. +.PP +The security team aims to complete the initial report triage within +two weeks' time. Complex issues that require significant discussion or +research may take longer. +.PP +If the security report cannot be reproduced or does not meet the team's +criteria for handling as a security issue, you will be notified by email +and given an opportunity to respond. +.PP +\fIIssue ID assignment\fR +.IX Subsection "Issue ID assignment" +.PP +Security reports that pass initial triage analysis are turned into issues +in the security team's private issue tracker. When a report progresses to +this point you will be provided the issue ID for future reference. These +identifiers have the format perl\-security#NNN or Perl/perl\-security#NNN. +.PP +The assignment of an issue ID does not confirm that a security report +represents a vulnerability in Perl. Many reports require further analysis +to reach that determination. +.PP +Issues in the security team's private tracker are used to collect details +about the problem and track progress towards a resolution. These notes and +other details are not made public when the issue is resolved. Keeping the +issue notes private allows the security team to freely discuss attack +methods, attack tools, and other related private issues. +.PP +\fIDevelopment of patches\fR +.IX Subsection "Development of patches" +.PP +Members of the security team will inspect the report and related code in +detail to produce fixes for supported versions of Perl. +.PP +If the team discovers that the reported issue does not meet the team's +criteria at this stage, you will be notified by email and given an +opportunity to respond before the issue is closed. +.PP +The team may discuss potential fixes with you or provide you with +patches for testing purposes during this time frame. No information +should be shared publicly at this stage. +.PP +\fICVE ID assignment\fR +.IX Subsection "CVE ID assignment" +.PP +Once an issue is fully confirmed and a potential fix has been found, +the security team will request a CVE identifier for the issue to use +in public announcements. +.PP +Details like the range of vulnerable Perl versions and identities +of the people that discovered the flaw need to be collected to submit +the CVE ID request. +.PP +The security team may ask you to clarify the exact name we should use +when crediting discovery of the issue. The +"Vulnerability credit and bounties" section of this document +explains our preferred format for this credit. +.PP +Once a CVE ID has been assigned, you will be notified by email. +The vulnerability should not be discussed publicly at this stage. +.PP +\fIPre-release notifications\fR +.IX Subsection "Pre-release notifications" +.PP +When the security team is satisfied that the fix for a security issue +is ready to release publicly, a pre-release notification +announcement is sent to the major redistributors of Perl. +.PP +This pre-release announcement includes a list of Perl versions that +are affected by the flaw, an analysis of the risks to users, patches +the security team has produced, and any information about mitigations +or backporting fixes to older versions of Perl that the security team +has available. +.PP +The pre-release announcement will include a specific target date +when the issue will be announced publicly. The time frame between +the pre-release announcement and the release date allows redistributors +to prepare and test their own updates and announcements. During this +period the vulnerability details and fixes are embargoed and should not +be shared publicly. This embargo period may be extended further if +problems are discovered during testing. +.PP +You will be sent the portions of pre-release announcements that are +relevant to the specific issue you reported. This email will include +the target release date. Additional updates will be sent if the +target release date changes. +.PP +\fIPre-release testing\fR +.IX Subsection "Pre-release testing" +.PP +The Perl security team does not directly produce official Perl +releases. The team releases security fixes by placing commits +in Perl's public git repository and sending announcements. +.PP +Many users and redistributors prefer using official Perl releases +rather than applying patches to an older release. The security +team works with Perl's release managers to make this possible. +.PP +New official releases of Perl are generally produced and tested +on private systems during the pre-release embargo period. +.PP +\fIRelease of fixes and announcements\fR +.IX Subsection "Release of fixes and announcements" +.PP +At the end of the embargo period the security fixes will be +committed to Perl's public git repository and announcements will be +sent to the perl5\-porters <https://lists.perl.org/list/perl5-porters.html> +and oss-security <https://oss-security.openwall.org/wiki/mailing-lists/oss-security> +mailing lists. +.PP +If official Perl releases are ready, they will be published at this time +and announced on the perl5\-porters <https://lists.perl.org/list/perl5-porters.html> +mailing list. +.PP +The security team will send a follow-up notification to everyone that +participated in the pre-release embargo period once the release process is +finished. Vulnerability reporters and Perl redistributors should not publish +their own announcements or fixes until the Perl security team's release process +is complete. +.SS "Publicly known and zero-day security issues" +.IX Subsection "Publicly known and zero-day security issues" +The security team's vulnerability remediation workflow assumes that issues +are reported privately and kept secret until they are resolved. This isn't +always the case and information occasionally leaks out before a fix is ready. +.PP +In these situations the team must decide whether operating in secret increases +or decreases the risk to users of Perl. In some cases being open about +the risk a security issue creates will allow users to defend against it, +in other cases calling attention to an unresolved security issue will +make it more likely to be misused. +.PP +\fIZero-day security issues\fR +.IX Subsection "Zero-day security issues" +.PP +If an unresolved critical security issue in Perl is being actively abused to +attack systems the security team will send out announcements as rapidly as +possible with any mitigations the team has available. +.PP +Perl's public defect tracker will be used to handle the issue so that additional +information, fixes, and CVE IDs are visible to affected users as rapidly as +possible. +.PP +\fIOther leaks of security issue information\fR +.IX Subsection "Other leaks of security issue information" +.PP +Depending on the prominence of the information revealed about a security +issue and the issue's risk of becoming a zero-day attack, the security team may +skip all or part of its normal remediation workflow. +.PP +If the security team learns of a significant security issue after it has been +identified and resolved in Perl's public issue tracker, the team will +request a CVE ID and send an announcement to inform users. +.SS "Vulnerability credit and bounties" +.IX Subsection "Vulnerability credit and bounties" +The Perl project appreciates the effort security researchers +invest in making Perl safe and secure. +.PP +Since much of this work is hidden from the public, crediting +researchers publicly is an important part of the vulnerability +remediation process. +.PP +\fICredits in vulnerability announcements\fR +.IX Subsection "Credits in vulnerability announcements" +.PP +When security issues are fixed we will attempt to credit the specific +researcher(s) that discovered the flaw in our announcements. +.PP +Credits are announced using the researcher's preferred full name. +.PP +If the researcher's contributions were funded by a specific company or +part of an organized vulnerability research project, we will include +a short name for this group at the researcher's request. +.PP +Perl's announcements are written in the English language using the 7bit +ASCII character set to be reproducible in a variety of formats. We +do not include hyperlinks, domain names or marketing material with these +acknowledgments. +.PP +In the event that proper credit for vulnerability discovery cannot be +established or there is a disagreement between the Perl security team +and the researcher about how the credit should be given, it will be +omitted from announcements. +.PP +\fIBounties for Perl vulnerabilities\fR +.IX Subsection "Bounties for Perl vulnerabilities" +.PP +The Perl project is a non-profit volunteer effort. We do not provide +any monetary rewards for reporting security issues in Perl. |