Edit: /usr/share/perl5/pod/perlsecpolicy.pod (19450B)
=encoding utf-8
=for stopwords
CVE perlsecpolicy SV perl Perl SDBM HackerOne Mitre
=head1 NAME
perlsecpolicy - Perl security report handling policy
=head1 DESCRIPTION
The Perl project takes security issues seriously.
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.
This document describes how the Perl security team operates and
how the team evaluates new security reports.
=head1 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
L
.
This address is a closed membership mailing list monitored by the Perl
security team.
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 security team lead L and
the L.
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.
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 L section.
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.
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 L
section.
=head1 WHAT ARE SECURITY ISSUES
A vulnerability is a behavior of a software system that compromises the
system's expected confidentiality, integrity or availability protections.
A security issue is a bug in one or more specific components of a software
system that creates a vulnerability.
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.
=head2 Software covered by the Perl security team
The Perl security team handles security issues in:
=over
=item *
The Perl interpreter
=item *
The Perl modules shipped with the interpreter that are developed in the core
Perl repository
=item *
The command line tools shipped with the interpreter that are developed in the
core Perl repository
=back
Files under the F directory in Perl's repository and release tarballs are
developed and maintained independently. The Perl security team does not handle
security issues for these modules.
=head2 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.
As a general rule, a bug in Perl needs to meet all of the following
criteria to be considered a security issue:
=over
=item *
The vulnerable behavior is not mentioned in Perl's documentation
or public issue tracker.
=item *
The vulnerable behavior is not implied by an expected behavior.
=item *
The vulnerable behavior is not a generally accepted limitation of
the implementation.
=item *
The vulnerable behavior is likely to be exposed to attack in
otherwise secure applications written in Perl.
=item *
The vulnerable behavior provides a specific tangible benefit
to an attacker that triggers the behavior.
=back
=head2 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.
The following is a list of commonly reported bugs that are not
handled as security issues.
=head3 Feeding untrusted code to the interpreter
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.
=head3 Stack overflows due to excessive recursion
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.
=head3 Out of memory errors
Common Perl constructs such as C, the C 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.
=head3 Escape from a L compartment
L restrictions and L compartments are not supported as
security mechanisms. The Perl parser is not designed to evaluate
untrusted code.
=head3 Use of the C and C
pack templates
These templates are unsafe by design.
=head3 Stack not reference-counted issues
These bugs typically present as use-after-free errors or as assertion
failures on the type of a C. 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.
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.
=head3 Thawing attacker-supplied data with L
L is designed to be a very fast serialization format.
It is not designed to be safe for deserializing untrusted inputs.
=head3 Using attacker supplied L databases
The L module is not intended for use with untrusted SDBM
databases.
=head3 Badly encoded UTF-8 flagged scalars
This type of bug occurs when the C<:utf8> PerlIO layer is used to
read badly encoded data, or other mechanisms are used to directly
manipulate the UTF-8 flag on an SV.
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.
=head3 Issues that exist only in blead, or in a release candidate
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.
=head3 CPAN modules or other Perl project resources
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.
=head3 Emulated POSIX behaviors on Windows systems
The Perl interpreter attempts to emulate C, C, C
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.
=head2 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.
=head3 Regular expressions
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.
The evaluation of untrusted regular expressions while C