perlsecpolicy - Perl 安全报告处理策略
Perl 项目非常重视安全问题。
及时有效地处理安全报告的责任已委派给一个安全团队，该团队由 Perl 核心开发人员的一部分组成。
本文档描述了 Perl 安全团队如何运作以及该团队如何评估新的安全报告。
如果您认为在 Perl 解释器或核心 Perl 代码库中维护的模块中发现了安全漏洞，请将详细信息发送至 [email protected]。此地址是一个封闭的成员邮件列表，由 Perl 安全团队监控。
您应该在 72 小时内收到对您的报告的初步答复。如果您在此期间未收到答复，请联系 Perl 指导委员会。
当安全团队成员回复您的邮件时，他们通常会在答复的“收件人”或“抄送”字段中包含 [email protected] 地址。这允许所有安全团队成员关注讨论并在需要时插话。在发送后续答复时，请使用电子邮件客户端的“全部回复”功能，以便整个安全团队都能收到邮件。
安全团队将评估您的报告，并初步确定它是否可能符合团队处理的问题范围。有关如何确定这一点的一般准则在 “什么是安全问题” 部分中有详细说明。
如果您的报告符合团队的标准，将在团队的私有问题跟踪器中打开一个问题，并且您将收到问题的 ID 号。问题标识符的格式为 perl-security#NNN。在您发送的任何后续邮件中包含此标识符。
安全团队将定期发送有关您问题状态的更新，并指导您完成漏洞补救过程所需的任何进一步操作。漏洞通常会经历的阶段在 “我们如何处理安全问题” 部分中有说明。
漏洞是软件系统的一种行为，它会损害系统的预期机密性、完整性或可用性保护。
安全问题是软件系统的一个或多个特定组件中的缺陷，它会造成漏洞。
用 Perl 编程语言编写的软件通常由许多不同团队编写的多层软件组成。确定复杂现实世界应用程序的哪个特定层导致了易受攻击的行为可能非常复杂，但这是修复漏洞的关键部分。
Perl 安全团队处理以下安全问题
Perl 解释器
在核心 Perl 存储库中开发的与解释器一起提供的 Perl 模块
在核心 Perl 存储库中开发的与解释器一起提供的命令行工具
Perl 存储库和发布 tarball 中 cpan/ 目录下的文件由独立开发和维护。Perl 安全团队不会直接处理这些模块的安全问题，但由于此代码与 Perl 捆绑在一起，因此我们将协助将问题转发给相关维护人员，并且你仍然可以向我们秘密报告这些问题。
Perl 被设计为一种快速灵活的通用编程语言。Perl 解释器和 Perl 模块使编写安全可靠的应用程序变得容易，但它们确实存在局限性。
作为一般规则，Perl 中的错误需要满足以下所有条件才能被视为安全问题
易受攻击的行为未在 Perl 的文档或公开问题跟踪器中提及。
易受攻击的行为不是由预期行为暗示的。
易受攻击的行为不是实现的公认限制。
易受攻击的行为很可能在用 Perl 编写的其他安全应用程序中受到攻击。
易受攻击的行为为触发该行为的攻击者提供了具体的切实利益。
某些类别的错误经常向安全团队报告，但不符合上述条件。
以下是不作为安全问题处理的常见报告错误列表。
Perl 解析器并非设计用于评估不受信任的代码。如果您的应用程序需要评估不受信任的代码，它应该依赖于操作系统级别的沙箱来确保其安全性。
过度递归通常是由不强制对输入进行限制的代码引起的。Perl 解释器假设应用程序会强制对递归进行限制。
诸如 pack、x 运算符和正则表达式的常见 Perl 构造接受数字量词，这些量词控制分配多少内存来存储中间值或结果。如果您允许攻击者提供这些量词并消耗所有可用内存，Perl 解释器不会阻止它。
Opcode 限制和 Safe 隔间不受支持作为安全机制。Perl 解析器并非设计用于评估不受信任的代码。
p 和 P pack 模板这些模板在设计上是不安全的。
这些错误通常表现为释放后使用错误或对 SV 类型进行断言失败。堆栈未引用计数崩溃通常发生在代码同时修改引用或 glob 并使用该 glob 或引用引用的值时。
这种类型的错误是 Perl 解释器的一个长期存在的问题，在正常代码中很少发生。此类错误的示例通常假设攻击者提供的代码将由 Perl 解释器评估。
Storable 被设计为一种非常快速的序列化格式。它并非设计为安全地反序列化不受信任的输入。
不建议将 SDBM_File 模块用于不可信的 SDBM 数据库。
当使用 :utf8 PerlIO 层读取编码错误的数据或使用其他机制直接操作 SV 上的 UTF-8 标记时，就会发生此类错误。
编码错误的 UTF-8 标记 SV 不是有效的 SV。以这种方式创建 SV 的代码会破坏 Perl 的内部状态。
blead 分支和 Perl 候选版本不提供安全支持。仅存在于 Perl 预发布版本中的安全缺陷通过常规错误报告和解决流程进行处理。
Perl 安全团队专注于 Perl 解释器和核心 Perl 代码库中维护的模块。该团队没有特殊权限来修复 CPAN 模块、用 Perl 编写的应用程序、Perl 项目网站、Perl 邮件列表或 Perl IRC 服务器。
Perl 解释器尝试在 Windows 系统上模拟 fork、system、exec 和其他 POSIX 行为。这种模拟有很多怪癖，在 Perl 的公共问题跟踪器中都有详细记录。更改这些行为会对 Windows 上的现有用户造成重大干扰。
Perl 解释器中的一些错误发生在代码库中既对安全敏感又容易在正常使用中发生故障的区域。
通常可以安全地编译和匹配不可信的正则表达式，但有几个注意事项。Perl 正则表达式引擎的以下行为由开发人员负责限制。
在 use re 'eval'; 生效时评估不可信的正则表达式永远不安全。
无法保证正则表达式在任何特定的有限时间范围内编译或评估。
在编译或评估正则表达式时，它们可能会消耗所有可用的系统内存。
正则表达式可能会导致过度递归，从而使 perl 解释器停止。
一般来说，不要指望 Perl 的正则表达式引擎能够抵抗拒绝服务攻击。
这些模块依赖于外部库来与数据库文件进行交互。
读取和写入这些文件格式导致的错误通常是由底层库实现引起的，而不是 Perl 中的安全问题。
Perl 错误处理底层库意外有效返回值的错误可能被视为 Perl 中的安全问题。
perl 解释器对算法复杂度攻击相当稳健。它并非对这些攻击免疫。
算法复杂度错误依赖于解释器处理攻击者提供的大量数据，通常不被视为安全问题。
有关更多信息，请参阅 perlsec 中的“算法复杂度攻击”。
Perl 安全团队遵循负责任的披露惯例。安全问题将保密，直到大多数用户都可以轻松获得修复程序。这最大程度地降低了用户面临的 Perl 漏洞固有风险。
暂时向用户隐瞒问题是确保用户安全所必需的权衡。永久向用户隐瞒问题并非目标。
当您私下向 [email protected] 联系地址报告安全问题时，我们通常希望您在处理报告时遵循负责任的披露惯例。如果您无法或不愿意在用户可以使用修复程序之前对问题保密，您应该在初始报告中明确说明这一点。
安全团队的漏洞修复工作流程旨在尽可能公开和透明地了解您的安全报告状态。
新的漏洞报告将在到达安全团队的邮件列表后 72 小时内收到初始回复。如果您在此期间未收到任何回复，请联系 Perl 指导委员会。
安全团队发出的初始回复将确认已收到您的消息，并提供安全团队分类分析的预计时间范围。
安全团队将评估报告，并确定报告是否可能符合作为安全问题处理的标准。
安全团队的目标是在两周内完成初始报告分类。需要大量讨论或研究的复杂问题可能需要更长时间。
如果无法重现安全报告或不符合团队作为安全问题处理的标准，您将收到电子邮件通知，并有机会做出回应。
通过初始分类分析的安全报告将转为安全团队的私人问题跟踪器中的问题。当报告进行到此点时，您将获得问题 ID 以供将来参考。这些标识符的格式为 perl-security#NNN 或 Perl/perl-security#NNN。
分配问题 ID 并不确认安全报告代表 Perl 中的漏洞。许多报告需要进一步分析才能得出该结论。
安全团队的私人跟踪器中的问题用于收集有关问题详情并跟踪解决进度。在问题解决时，这些注释和其他详细信息不会公开。保持问题注释私密使安全团队能够自由讨论攻击方法、攻击工具和其他相关隐私问题。
安全团队成员将详细检查报告和相关代码，以针对受支持的 Perl 版本生成修复程序。
如果团队发现报告的问题不符合此阶段团队的标准，您将收到电子邮件通知，并在问题关闭之前有机会做出回应。
在此期间，团队可能会与您讨论潜在的修复程序，或为您提供补丁以进行测试。在此阶段不应公开共享任何信息。
一旦问题得到完全确认并找到潜在的修复程序，安全团队将为该问题请求一个 CVE 标识符，以便在公开公告中使用。
需要收集诸如容易受到攻击的 Perl 版本范围和发现该缺陷的人员身份等详细信息，才能提交 CVE ID 请求。
安全团队可能会要求您澄清在表彰发现该问题时我们应该使用的确切名称。“漏洞表彰和赏金”部分说明了我们对此表彰的首选格式。
一旦分配了 CVE ID，您将通过电子邮件收到通知。此时不应公开讨论该漏洞。
当安全团队确信安全问题的修复程序已准备好公开发布时，将向 Perl 的主要再发行商发送预发布通知公告。
此预发布公告包括受该缺陷影响的 Perl 版本列表、对用户风险的分析、安全团队已制作的补丁以及安全团队掌握的有关缓解措施或将修复程序反向移植到旧版 Perl 的任何信息。
预发布公告将包括一个具体的目标日期，届时将公开宣布该问题。预发布公告和发布日期之间的时段允许再发行商准备和测试自己的更新和公告。在此期间，漏洞详细信息和修复程序将被禁止，不应公开共享。如果在测试期间发现问题，此禁止期可能会进一步延长。
您将收到与您报告的具体问题相关的预发布公告部分。此电子邮件将包括目标发布日期。如果目标发布日期发生更改，将发送其他更新。
Perl 安全团队不会直接制作官方 Perl 版本。该团队通过将提交放入 Perl 的公共 git 存储库并发送公告来发布安全修复程序。
许多用户和再发行商更喜欢使用官方 Perl 版本，而不是将补丁应用到旧版本。安全团队与 Perl 的发行经理合作，以实现此目的。
通常在预发布禁止期间在私有系统上制作和测试新的官方 Perl 版本。
在禁运期结束时，安全修复将提交到 Perl 的公共 git 存储库，并且公告将发送至 perl5-porters 和 oss-security 邮件列表。
如果官方 Perl 版本已准备就绪，它们将在此时发布，并在 perl5-porters 邮件列表中宣布。
一旦发布过程完成，安全团队将向参与预发布禁运期的每个人发送后续通知。漏洞报告者和 Perl 再发行者不应在 Perl 安全团队的发布过程完成之前发布自己的公告或修复。
安全团队的漏洞修复工作流程假定问题是私下报告的，并在解决之前一直保密。情况并非总是如此，而且在修复准备就绪之前，信息偶尔会泄露。
在这些情况下，团队必须决定秘密操作是增加还是降低 Perl 用户的风险。在某些情况下，公开安全问题带来的风险将允许用户进行防御，而在其他情况下，引起对未解决的安全问题的注意将使其更有可能被滥用。
如果 Perl 中未解决的关键安全问题正被积极滥用以攻击系统，安全团队将尽快发出公告，其中包含团队可用的任何缓解措施。
Perl 的公共缺陷跟踪器将用于处理该问题，以便受影响的用户能够尽快看到其他信息、修复和 CVE ID。
根据关于安全问题的信息的突出程度以及该问题成为零日攻击的风险，安全团队可能会跳过其正常修复工作流程的全部或部分。
如果安全团队在 Perl 的公共问题跟踪器中识别并解决重大安全问题后了解到该问题，团队将请求 CVE ID 并发送公告以通知用户。
Perl 项目感谢安全研究人员为确保 Perl 安全所做的努力。
由于这项工作的大部分对公众是不可见的，因此公开表彰研究人员是漏洞修复过程中的重要组成部分。
当安全问题得到修复时，我们会在公告中尝试表彰发现该漏洞的特定研究人员。
表彰使用研究人员首选的全名进行宣布。
如果研究人员的贡献由特定公司资助或属于有组织的漏洞研究项目的一部分，我们将在研究人员的要求下为该小组包括一个简称。
Perl 的公告使用英语和 7 位 ASCII 字符集编写，以便在各种格式中复制。我们不会在这些表彰中包含超链接、域名或营销材料。
如果无法确定漏洞发现的适当表彰，或者 Perl 安全团队和研究人员之间对于如何表彰存在分歧，则该表彰将从公告中省略。
Perl 项目是一项非营利志愿者活动。我们不会为报告 Perl 中的安全问题提供任何金钱奖励。