LWN：GNU工具链项目的安全规则！

关注了就能看到更多这么棒的文章哦～

Security policies for GNU toolchain projects

By Jonathan Corbet
September 28, 2023
Cauldron
ChatGPT translation
https://lwn.net/Articles/945536/

创建CVE流程，是为了能应对真实存在的问题的，但越来越清楚，CVE编号本身也正在制造问题。在2023年GNU工具Cauldron会议上，Siddhesh Poyarekar表达了工具链（toolchain）开发人员在与安全研究人员讨论CVE编号分配时所感到的困扰。作为回应，GNU工具链社区正试图更好地界定其软件中哪些问题被视为与安全相关，哪些不是。

他提到，对binutils工具进行模糊测试已经变得相当普遍；这是“模糊测试流行”的一个例子，而这种现象在更广泛的范围内也在发生。他特别强调了模糊测试的重要性，但随后发生的事情则不尽如人意。研究人员在申请CVE编号时其实很多是为那些实际上并非安全问题的bug而申请的。这种“感染（infection）”现象从binutils传播到了工具链生态系统的其他部分。他认为整个CVE系统都有问题。人们会报告问题并获得CVE编号，但相关方面并没有真正理解这些漏洞被发现的上下文。结果，大量的开发时间都花在了重新构建软件包、对fix进行backport等工作上，为了解决一些并非真正安全bug的一些问题。

Poyarekar希望为帮security工作更加明确重点，并将这项工作引导到更有益的方向。这需要更好地理解什么构成了安全问题。简而言之，安全问题（security issue）是使得用户可以执行其本来无权限执行的操作的一些漏洞。这类问题可以分为几个子类；例如，存在会影响整个系统完整性的“直接漏洞（direct vulnerabilities）”。还有其他类型比如某个安全功能（如hardening）未能按照预期来正常工作，或一些设计缺陷可以被恶意攻击者利用。前两种类型通常会在分配CVE编号后得到修复。不过，设计缺陷也可能由于热衷的研究人员而获得CVE编号，但往往只会导致“手足无措（hand wringing）”。

Setting the context

在涉及安全问题时，他表示，上下文是至关重要的。任何特定漏洞在哪种用例下可以被滥用？他正在为工具链（toolchain）项目设定上下文，这包括定义每种情况下的使用模型，然后确定每种情况下的安全期望。例如，不能指望GCC在每种情况下都是安全的。只有在设定了这个上下文之后，才能制定安全问题的处理流程。

关于运行时库（runtime libraries），Poyarekar指出，Florian Weimer已经为GNU C库定义了一个安全上下文；这在项目的顶级 SECURITY.md 文件中有详细说明。这个做法成功地对安全问题进行了更好的区分。总的来说，运行时库必须提供最高标准的安全性。但这也是因情况而异：例如，将未初始化的指针传递给 memcpy() 并不是glibc的安全问题；使用如 gets() 这样的函数也不是glibc的安全问题。

此外，并非每个可加载的共享对象（loadable shared object）都该被视为这种类型的运行时库。例如，libiberty和libbfd等库并不是用于在任意情况下使用的；它们被期望是健壮的，但并不适用于安全上下文。这些库中的漏洞不应被视为安全问题。

Carlos O‘Donell问，如果针对特定库所建立的定义不符合他的需求，那么会发生什么。例如，他说，普遍认为无法阻止正则表达式消耗任意数量的内存，因此可以这么理解，程序无法接受来自不受信任源的任意正则表达式并仍然保持安全。如果他希望能够安全地评估用户提供的正则表达式（并希望库能支持这个做法），他需要如何修改策略？答案是这将需要与开发人员进行讨论，他们将根据情况评估此类请求。

另一个上下文是分析程序（例如 objdump 这个工具）。人们期望这类程序可以接受任意输入，因此它们应该具有鲁棒性。但不能期望在面对不受信任的输入时它们能够保持安全；在这种情况下，它们必须在一个沙盒中使用。有观众反对采取“无限制（all bets are off）”的态度，即使存在错误，也必须有一定的限制；例如，相关bug不应引发特权提升。Poyarekar同意，但说，例如，暴露私有SSH密钥可能在这些限制之内。

转向编译器，他指出，可以期望编译器为任何有效输入生成输出，但验证通常仅限于确保语法和语义的正确性。任何进一步的保证都取决于所涉及的语言规范。在面对不受信任的输入时，编译器应具有鲁棒性；如果它crash，那就是一个bug，但不是一个security bug。任何期望将这种输入提供给编译器并保持系统的完整性的人都是天真的。应该在沙箱中进行不受信任代码的编译；这就是Compiler Explorer所做的事情。

Authority

进行最终总结时，Poyarekar说GNU工具链项目可以做的第一件事是定义一个安全策略（security policy）；研究人员通常期望在项目存储库的顶级 SECURITY.* 文件中找到这个安全策略。这应有助于澄清一些类型的错误并不属于安全问题，希望能够避免生成一些不必要的CVE。

不过，项目可以在安全问题的分级中发挥更积极的作用。CVE编号通常由CVE编号管理机构（CNAs）分配，通常几乎不进行调查；他说这个过程的状态很“糟糕”。大多数项目没有指定的CNA，这意味着研究人员可以联系任何一位能决定分配CVE编号的人员。这些CNA可能根本不进行研究，但仍然分配CVE编号；一旦分配完毕，后续进行处理的工作是很痛苦的。

David Edelsohn指出，一些研究人员正在利用这个过程，声称他们发现了更多的CVE编号，他们特别喜欢那些倾向于为其分配较高严重性级别的CNAs。他说这是一个完全被操纵了的流程。Poyarekar同意，并说GNU工具链项目的解决方案是创建他们自己的CNA，以获得对这个过程的一定控制。

他说，GLibc的安全策略已经制定了一段时间，而Binutils也已经采纳了一项策略。此外，Binutils还允许Red Hat充当其CNA，这已经减缓了虚假CVE编号的生成。不过，对于工具链中的其他组件还有工作要做。GDB是一个悬而未决的问题；似乎有一些之前被拒绝的binutils的CVE现在重新提交到GDB中。GCC现在正在制定一项正在开发中的策略，并且GLibc也正在建立CNA。

他在会议结束时表示，工具链项目需要更好地掌握CVE流程以保持自己的理智，他正在寻找贡献者来协助完成这项任务。

[感谢Linux基金会支持我参加此次活动。]

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～