近日，Apache 软件基金会发布了“2020 年 Apache Software Foundation 安全报告”。在 2020 年累计收到的 18000 封电子邮件中，Apache 软件基金会确认 946 个非垃圾邮件对话。

具体说来，257 个对话（占 27%）是因为人们对 Apache 许可证感到困惑。因为许多项目（不仅仅 ASF 旗下的那些）都使用 Apache 许可证，当看到 Apache 许可证，并且不了解它的具体情况时，很多人会一头雾水。例如，最常见的一个例子是智能手机设置菜单中显示的许可证，这通常是由于系统包含了谷歌在 Apache 许可证下发布的软件。

对于这类邮件，Apache 软件基金会称，“虽然这类邮件数量是 2019 年的两倍，但是我们不再回复这些电子邮件。”

其次，有 220 个对话（占 23%）主要关于人们询问非安全性（通常是支持类型）的问题。

此外，还有 376 份报告涉及 101 个顶级项目中的新漏洞。其中，有 341 份报告让 Apache 软件基金会安全委员会分配了 151 个 CVE 名称。据悉，Apache 安全委员会负责 CVE 名称分配，并且是 Mitre 候选命名机构（CNA）。

值得注意的事件

这份报告提到了 2020 年一些值得讨论的事件，包括：

2 月：Tomcat CVE-2020-1938中的一个问题被赋予 Ghostcat，引起媒体关注，并在 Tomcat 发布建议前由一家第三方协调中心披露（尽管该问题已在新版本的 Tomcat 中得到解决）。尽管它被利用的后果很严重，但仅影响将不受保护的 AJP 连接器暴露给不受信任网络的 Tomcat 安装（即使没有这个问题，这也不是一件好事）。这限制了受影响的安装数量。此问题公开了多个概念验证漏洞，包括一个 Metasploit 漏洞。5 月：CISA 发布了十大被经常利用的漏洞列表，包括CVE-2017-5638，这是 Apache Struts 2 中的远程命令执行（RCE）漏洞，于 2017 年披露并修复。据悉，这个问题曾在实践中被利用，但第一次漏洞利用事件是在修复建议和更新发布后才被发现的。7 月：Apache Guacamole 1.1.0 和更早版本容易受到 RDP，CVE-2020-9497和CVE-2020-9498中一些问题的影响。如果用户连接到恶意或受损的 RDP 服务器，则可能导致内存泄露和可能的远程代码执行。8 月：Apache Struts（CVE-2019-0230）中的一个漏洞可能导致任意代码执行。为了利用这个漏洞，攻击者需要将恶意的对象图导航语言（OGNL）表达式注入到 OGNL 表达式内使用的属性中。尽管 Struts 针对潜在的表达式注入有缓解措施，但 2.5.22 之前的版本还是暴露了一个攻击向量，这个漏洞已在此问题的更新中修复。存在针对此问题的 metasploit 漏洞利用事件。11 月：以前，每个 ASF 项目都负责编写自己的 CVE 条目并将其提交给 Mitre。这会导致 CVE 数据库中的许多 Apache 问题更新遭遇拖延，因为由旧有格式导致问题的条目经常被拒绝。我们发布了一个内部工具，为处理安全问题的项目提供了一种编辑、验证并将其条目提交给 Mitre 的方法。Apache 安全委员会的目标是在发布问题的一天之内更新 CVE 数据库。12 月：CVE 项目发布了一个新的自动化 API，ASF 成为第一个使用它来获得实时 CVE 名称的组织。现在，安全团队不再按事先要求的方式保存名称，而是按需分配名称，这个服务则将处理发送给 PMC 的电子邮件，以及流程中其他之前由人工处理的部分。Apache 安全委员会预计 2021 年将出现更多的自动化技术，能进一步简化项目的 CVE 流程。Apache OFBiz（CSRF，CVE-2019-0235）、Apache OpenMeetings（DoS，CVE-2020-13951）、Apache Flink（任意读/写 RCECVE-2020-17518，CVE-2020-17519）的 2020 年问题中也发布了一些概念证明或 Metasploit 漏洞。

据悉，这份报告来自 Apache Software Foundation（ASF）安全委员会。它负责监督并协调总计 340 多个 Apache 项目中的漏洞处理事宜。该委员会成立于 2002 年，由志愿者组成，有一套统一的流程来处理问题。

任何人只要在 Apache 项目中发现安全问题，他都可以将其报告给 security@apache.org，这里会记录问题并传递给相关的专职安全团队或私有项目管理委员会（PMC）处理。安全委员会负责监视在所有地址中报告的所有问题，并在整个漏洞生命周期中持续跟踪问题。安全委员会负责确保问题被正确处理，并将针对项目尚未解决的问题和职责做出主动提醒。

整个流程大致分为四个阶段：

分类：安全委员会的目标是在三个工作日内处理发送到 security@apache.org 地址的邮件。他们不会对此快速做出统计或报告，因为要先评估每个问题的严重性，并适当地分配有限的资源。这个地址由来自不同项目 PMC 的极少数志愿者管理。安全团队将报告转发给 PMC 后，他们将回复给报告者。因此，如果你已向安全委员会报告了问题，但一周后仍未收到任何回复，可以继续发送后续电子邮件。有时，报告者会发送附有大型 PDF 文件甚至是漏洞视频的报告，但附件并没有成功发送过来，因此，请确保所有后续操作都是简单的纯文本电子邮件。调查：将报告发送到项目管理委员会的私有名单后，分类和调查的过程会随时间而变化，这具体取决于项目、资源的可用性以及要评估问题的数量。当安全委员会将报告发送到这个私有列表时，它并不会发给每一位项目提交者，因此每个项目中能调查和响应的人员数量要少得多。作为一般准则，安全委员会会试着确保项目在报告后的 90 天内分类各种问题。ASF 安全小组会追查超过 90 天还没有分类的问题。修复：对安全问题进行分类和接受后，解决问题的时间表取决于项目本身的时间表。严重性较低的问题通常会等到计划中的未来版本里解决。公告：安全委员会的流程允许项目在漏洞公布与修复版本推送之间有几天的延迟，以让各个镜像有时间做准备。所有漏洞都通过 announce@apache.org 列表发布。安全委员会现在的目标是在公告发布后的一天内，将它们显示在公共 Mitre 列表中。

Apache 软件基金会安全副总裁 MarkCox 写道，“Apache 软件基金会项目具有高度的多样性和独立性。它们有着不同的语言、社区、管理和安全模型。但是，各个项目的一个共同点是处理报告的安全问题的一致流程。ASF 安全委员会与项目团队、社区和报告者密切合作，以确保快速、正确地处理问题。这种负责任的监督是 Apache Way 的原则，有助于确保 Apache 软件稳定且可信任。”

延伸阅读：

Pulsar 和 Kafka 基准测试报告（下）-InfoQ

关注我并转发此篇文章，即可获得学习资料~若想了解更多，也可移步InfoQ官网，获取InfoQ最新资讯～