LWN：不在CVE列表里的安全漏洞

点击上方蓝色字关注我们~

CVE-less vulnerabilities

By Jake Edge
June 25, 2019

近年来，free software里面有更多的bug被报告出来，从很多方面来说，这是一件好事，当然也有一些负面影响。而像OSS-Fuzz这样的项目也贡献不小，通过自动测试报出很多bug，其中不少都是安全相关的。剧增的bug数量在很多自由软件的项目里都有出现，导致没有足够的人力去修复这些问题，甚至都没有精力去过滤和分类。在oss-security mailing list上近期就有一些关于这个话题的讨论。

Few CVEs

Alex Gaynor先提出了CVE的分配的这个问题。他认为OSS-Fuzz在2016年成立后表现非常成功（只是很可悲的是只有3000个被作为security bugs来处理）。大多数bug都没有被分配到CVE编号，可能有如下原因：很难获得CVE的承认、没有人为的推动力去获取CVE编号，以及所发现的bug数量太多了。虽然并不是所有的安全风险都得要跟CVE一一对应，不过CVE还是有好处的：“CVE本身并不重要，它的价值在于所有的后续处理都会使用CVE来作为起始信息，例如Linux发行版会根据这些信息来确认哪些bug fix patch需要被backport回来，而docker security scanner在扫描系统里的安全漏洞也是基于CVE列表，还有企业的thread-intelligence feeds这些风险通告等。”

他介绍了自己把ImageMagick和GraphicsMagick集成到OSS-Fuzz里的过程。然后用他当时在ImageMagick里发现的一个bug（随意挑选了一个），在Ubuntu 16.04 LTS里面这个bug仍然存在。此外，已经有100多个安全相关的bug（分布在多个项目）被OSS-Fuzz团队公布出来（因为已经超过了90天的保密期），但是都还没有正式fix。Gaynor坦率的说他没有什么好建议，希望能把这个话题开个头，让大家来一起想想办法。

Greg Kroah-Hartman认为，这种挑选一些fix来backport的工作模式最终肯定会失败的。他建议就推动用户都使用最新版本。他是stable kernel的维护者，同时维护这多个stable kernel版本，其实他自己也是在挑选fix来backport（哈哈）。这些stable kernel就会从mainline收集那些已知有用的fix，然后backport过来。也就是这些stable kernel其实包含了那些重要的bug fix，而不是根据CVE编号来选择。他实际上是建议大家都升级到相应的stable kernel的最新版本上去。

不过Yves-Alexis Perez觉得这个工作模式不一定适合所有人：“情感上我赞同这种看法，我们确实应该对upgrade做的更好。不过实际上来说不是所有项目都能安全地升级到最新版本的。最终用户和IT管理员在很多情况下更加关注稳定性，也希望避免出现质量回退。只要有一个回退bug出现了，通常在上游代码就要花一段时间才能fix。此外，有一些项目的最新版本可能依赖很多个其他项目的最新版本。有时候这种依赖关系会导致整个系统的大范围升级。”

Kroah-Hartman认为，如果一定要在一个已经公开的安全bug，和一个可能引入regression（质量退步）的升级之间选择，那么有什么好犹豫的呢？他认为各个项目和相应的用户都应该努力避免出现regression：“Regression总是无法避免的，毕竟我们是人类（都会犯错），但是有很多方法来减轻影响（测试，回退，阻止开发者故意引入的问题）。现在还没有这种工作的项目一定要意识到需要改变了，否则用户会离开的。”

Graphics Magick维护者Bob Friesenhahn认为OSS-Fuzz发现的很多bug都不是真正意义上的CVE。当然这些也都是值得花时间来fix的bug。他通常修复的那些真正的安全问题通常都是由Debian项目参与者审查出来的，所以这些一般都有CVE编号，也都在Debian的bug tracking系统上很好的管理起来了。不过，在bug发现者和修复者之间还是有一些交流不够顺畅：“安全相关的bug通常都很难确认或者修复。社区里有很多高质量的bug report，不过花功夫fix bug的人更少ixie。其实非常期望有更多人帮助来fix。最终的目标是让提供出来的开源软件能有尽量少的bug，并且仍然可用。因此只是报出bug的话，还是不够的。”

Hanno Böck赞同OSS-Fuzz bugs很多并不是真正的security bugs的说法，尤其是针对format parser这样的程序：“哪怕是那些看起来很吓人的漏洞，例如write buffer overflow（写缓冲溢出）或者use after free，通常来说他们也不是那么容易被利用来攻击系统的。所有现代的发行版都有stack canaries(一种防止缓冲区溢出的机制)，ASLR 和不允许执行代码的内存属性设置。我理解，虽然总是有可能绕过这些防护措施的，不过想在那些non-scripting scenarios（无法写脚本的场景，例如image parser这种图像格式解析器场景）来利用这些功能做攻击，都是非常困难的，甚至完全没有可能用来攻击。”

他也指出，这种报出很多bug但是只有很少被fix的现象，并不是新现象，不过现在确实发展的速度更加快了。各个发行版其实也很难完全按照他们承诺的做。虽然他们承诺要把所有security fix都backport过来，不过他们不一定有足够的人手来真正做到这一点：“可能这里我们能做的就是面对现实，也许各个发行版提供方应该更坦率一些，列清楚哪些是能做到的，哪些是不能做到的。例如你在一个高风险环境里运行parser程序，那么就不能指望某些LTS发行版里面的已经很久以前的软件版本也能保护你。”

Gaynor也认为这个问题不是个新问题，不过他认为“OSS-Fuzz发现漏洞的规模更大，确实加剧了这个问题”。他也建议大家不要过于轻视OSS-Fuzz报出来的有潜在安全风险的bug。他列出了两个例子，都是利用了哪些原本以为很难或者完全没可能利用的bug来进行的攻击。

Project responsibilities

David A. Wheeler认为Böck的看法很有道理，发行版提供商确实有点高估他们自己的能力了。不过他认为这些project本身也是问题的一部分。他列举了一些想法，关于如何让这些project能做的更好。很多都是基于他领导的Core Infrastructure Initiative Best Practices project的一些建议。第一个建议跟security本身没有直接关系，不过指明了讨论的一个核心问题：“project开发者应该想尽办法来避免破坏向后兼容。大家都赞同有时候是需要改变，不过project应该要提供更加顺畅的升级体验（对废弃API有较长时间的deprecation周期，提供一些用其他名字明明的新API给大家一些时间过渡，等等方法都可以用）。特别是，我认为发行版之所以需要经常backport而不是用当前版本，主要的原因就是因为用户很害怕碰到向后兼容问题。如果所有project都能避免这个问题，那么发行版提供商就不会害怕来做升级。”

Alan Coopersmith, X.Org项目的一个维护者，认为Wheeler的列表有他的价值，不过拿X.Org来说，由于开发者数量不够，没法按他说的那种情况操作：“我知道我们不是唯一一个面临这种问题的FOSS项目”。这里的部分问题在于使用这些软件的公司没有做好他们该做的一部分：“当他们在用这个软件来赚钱的时候，却没有用这些收入来支持开发者继续改进软件，这样的话他们的一些问题没有得到解决也是很正常的。”

Marcus Meissner也认为这个流程中还是有些割裂，包括找出bug，分析bug，修正bug，报出security bug等等。他看到的两个应该改进的领域，分别是bug fix流程中更多应用自动化，以及使用更详尽的统一数据记录来记录比CVE信息更多的issue。不过Meissner也认为CVE的分配目前是一个需要人为操作的流程，最好也能改进为自动化操作。Dmitry Vyukov，syzkaller fuzzer的开发者，在想fuzzer这种技术是不是应该能利用来自动创建CVE：“大家怎么看待自动进行CVE的分配？这样就肯定能让这些bug得到vendor的工多注意（因为这些CVE是在他们的产品里发生的）。我觉的很应该这样做，因为OSS-Fuzz和syzbot都已经具有很高的自动化程度了。不过我有点担心收到这些分配的人会不会创建个邮件规则自动把它扔到垃圾箱里去:) ”

Alexander Potapenko认为OSS-Fuzz的报告里面的信息已经足够用于判断某个bug是否是安全漏洞了。不过，Wheeler指出，CVE通常都是指真实的漏洞（actual vulnerabilities）：“很多组织里在看到CVE出现的时候都会进行快速升级流程，其他情况下则会稳重推进升级。”不过正如Simon McVittie指出的，如果对那些不是真实安全漏洞的bug也分配CVE编号的话，可能会起到适得其反的作用：“之所以人们愿意在看到CVE fix的时候进行快速升级，是因为这是一个合理的策略来平衡安全风险和regression（代码质量回退）风险。如果有很多CVE都是一些无法被利用来做实际安全攻击的bug，那么就相当于是在教育软件用户，他们可以随意忽略掉绝大多数的CVE，这样反而会导致那些真正的安全漏洞在生产系统上没有得到及时的修复。这样对大家都没有好处（除了攻击者会很高兴）。”

在这个邮件讨论逐渐冷却下来的时候，Gaynor贴了一个他在这轮讨论中看到的各种想法的总结，他觉得很高兴的时候，看起来所有想法都是有一定可操作性的。其中前两个是能在两个领域推进更好的自动化：CVE的编号申请、分配，这样fuzzer就可以利用这个功能；还有怎么评估风险漏洞是否可行，这个看起来有点难，不过也许是一个挺好的学术研究领域。最后一个想法是关于减少project里面新增的风险漏洞数量的：“虽然一直有一些争议，关于OSS-Fuzz和syzbot发现的bug中，有多大百分比的问题是真正可以利用的系统漏洞，但是毫无疑问它们报出了很多真正的系统漏洞。哪怕只有20%的比例，那就是意味着有超过600个系统漏洞。我们不应该先造出这么多的系统漏洞然后再用fuzzing技术来找到它们。总有一天这些bug的数量会彻底把我们淹没的。我们需要采用更多技术来在源头上避免这些漏洞，例如memory safe languages（内存安全的编程语言），这是今后能控制这种问题的一个重要环节。”

总的来说，这次的讨论非常广泛，仍在进行当中，因此可能会有更多的想法出现。很明显有很多安全相关的bug已经被发现了（并且数量仍在不断上升）。很多问题仍然没有拿到CVE编好。人们可能会争论说用户只要做升级就好了，不过非常明显多数人并不愿意这样做，尤其是没有一个特定的CVE风险逼着他升级的时候。他们主要是担心regression质量回退。此外，很多OSS-Fuzz等系统报出的bug一直没有得到fix，因为缺少代码贡献者。升级也要等到这些bug被修复之后才有用处。

Wheeler的观点认为project有很大的责任，不过哪怕是对Linux kernel（明确强调有no regression规则的），大多数人也是不愿意做升级的，而是宁愿好几个月，好几年，才会愿意升级到一个较新的kernel版本。发行版确实也是一个重要角色，不过他们宁愿backport一些fix，这样可能会导致其他地方出现一些regression问题。他们的关注点通常都在稳定性上，这也是导致需要维护多个长期稳定kerne版本的一个原因。这里都是一些很难解决的问题。

不过，也许Coopersmith的评论正是问题的症结，就是关于利用free software来盈利的公司。如果报出的问题确实是严重问题，影响公司的核心产品以及股票价格了，那么人们会更加愿意投入资源来解决（或者至少能大幅度降低发生概率）这个问题。目前这种事情还没有发生过。Heartbleed（一个OpenSSL的bug可能导致秘钥泄露）可能是我们碰到过的最接近的一个例子。

Heartbleed后来触发了Core Infrastructure Initiative项目的建立，已经做出了不少贡献，不过去年开始相关的活动变少了。这个倡议（initiative）是针对上述这个极其严重bug的响应措施。不过还有很多bug潜藏在我们的代码中，很可能会有比heartbleed更严重的。社区需要在造成损失之前采取更好的预防措施。

全文完

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

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～