从怀疑到公开的curl CVE

每个curl安全报告都始于有人在https://hackerone.com/curl上向我们提交问题。报告者会告知他们怀疑的问题及其性质。在我们处理期间，该报告将保持私密状态，仅对curl安全团队和报告者可见。

最近几个月，我们每周收到3-4份安全报告。该计划已运行超过六年，累计收到近600份报告。 团队成员通常在收到报告后一小时内做出首次回应。

评估

当前curl安全团队由七位经验丰富的curl维护者组成。我们立即开始分析和评估收到的问题及其主张。大多数报告并未识别出实际的安全问题，而是被迅速驳回并关闭。部分报告识别出非安全问题的普通错误，我们会将讨论转移到公共错误跟踪器。

这部分工作可能耗时数小时至数天，通常需要多位curl安全团队成员参与。 如果我们认为问题可能有效，会提出后续问题、测试可复现代码并与报告者讨论。

验证

只有一小部分 incoming 报告被确认为实际安全漏洞。我们与报告者合作，深入理解触发漏洞所需条件及缺陷可能导致的后果。共同设定问题严重等级（低、中、高、严重），并制定初步补丁——这也有助于确保我们真正理解问题。除非问题被认为严重，我们倾向于将新漏洞的发布与待定版本同步。我们的正常发布周期为八周，因此距离下次发布永远不会超过56天。

修复

对于被评为低或中等级别的安全问题，我们会在公共代码库中创建拉取请求——但不在公开沟通中提及问题的安全角度。通过这种方式，我们确保修复在待定版本发布前获得测试曝光和打磨时间。过去五年左右，在约80个已确认安全漏洞中，只有两个被评定为高于中等级别。而对于高或严重级别的漏洞修复，我们会在计划发布前约48小时合并到git仓库——以限制在正式公布前的暴露时间。我们需要在发布前将其合并到公共代码库，因为我们的整个测试基础设施和验证系统都基于公共源代码。

安全公告

接下来，我们编写详细的安全公告，解释问题、错误具体内容及其可能导致的后果——包括我们能想到的所有相关细节。这包括受影响curl版本的范围、引入问题的确切git提交记录、修复问题的提交记录，以及报告者和补丁作者的致谢等。我们的目标是提供行业内最优秀的安全公告。（我们还为少数关心此功能的用户提供JSON格式等版本。）我们当然也希望原始报告者参与其中，确保准确覆盖问题的所有角度。

CVE

作为CNA（CVE编号机构），我们自行为自己发现的问题保留和管理CVE ID。

预通知

在计划发布（同时发布CVE）前约一周，我们通过distros@openwall邮件列表通知相关问题，包括修复内容和计划发布时间。这为开源操作系统提供了一些准备时间和调整空间。

发布

在发布日，我们公布CVE详细信息并发布新版本。随后关闭HackerOne报告并向全世界披露。为了最大程度的透明和开放，我们在关闭后披露所有HackerOne报告。我们还会通知所有curl邮件列表和oss-security邮件列表关于新CVE的信息。有时我们当然会在同一版本中发布多个CVE。

奖金

HackerOne报告关闭并对外披露后，漏洞报告者可以向Internet Bug Bounty申请漏洞奖金，该组织将根据curl漏洞的严重程度向研究人员支付相应金额。

（本文原始文本曾用于我为Help Net Security所做的采访，此处经过调整和略微扩展。）

团队

当前在curl安全团队中默默无闻地处理所有这些工作的英雄们包括（排名不分先后）：

• Max Dymond
• Dan Fandrich
• Daniel Gustafsson
• James Fuller
• Viktor Szakats
• Stefan Eissing
• Daniel Stenberg