安全研究人员蓄意引入漏洞？该道歉的是这些自媒体们！

就在本周，诸多中文 IT 自媒体上都出现了如下耸人听闻的“原创”新闻：

乍一看，这好像是个挺大的瓜，不知情群众纷纷点击，可是读完这些新闻，且不从专业安全研究人员的角度来评论，单从这些新闻的标题和内容中充斥的无来源的主观评论（例如上来就是一句“Linus Torvalds 应该要气炸了”，实际上新闻事件和 Linus 毫无直接联系）和谬误（连新闻事件主要人物卢康杰教授的名字都没有确认的情况下就直接写成“陆康杰”，以及“Liunx 社区”这种滑稽的拼法），就可以看出来这些报道的质量之低，以及故意提及“华人教授”所充斥着的极度自卑的心态。我们不得不指出，这些对安全研究一无所知且毫无专业素养、只关心流量的中文 IT 自媒体，在毫无根据的情况下胡乱“撰写”所谓的“新闻”，是对专业知识的极大侮辱！事实上，这些新闻中提到的华人教授——在明尼苏达大学任职的卢康杰教授不仅不是这些报道（以及国内各种讨论社区的帖子）中想要表达的所谓“故意引入漏洞而灌水”的研究人员，反而是计算机安全研究领域的华人之光！因此，我们必须要站出来，从安全研究社区的角度对这个事件进行阐述，抨击这些极端的言论。

首先，让我们看看这次新闻中涉及的主要人物、领导了一系列相关安全研究的卢康杰教授是何许人也？我们很容易翻看到卢康杰教授的主页并读到他一系列相关研究工作。我们注意到，在新闻中提及的 2021 年 IEEE S&P 论文《On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits》发表之前，卢康杰教授研究团队在 Linux 内核的漏洞研究方向上已经取得了诸多显著的研究成果，包括：

• 2017 年发表在 NDSS 安全会议上的关于内核中uninitialized-use issues 的安全威胁远比大家想象中更为严重的研究论文；
• 2018 IEEE S&P 论文发现了 Linux 内核中 23 个新类型的 bug——double-fetch bugs；
• 2018 年 CCS 论文中提出了针对 Linux 内核中又一类特殊 bug——lacking-recheck  bugs 的检测方法并新发现 19 个问题；
• 2019 年 Usenix Security 论文中提出对内核中 missing-check bugs 大规模高效检测的研究，在 Linux 内核中新发现了 278 个 missing-check bug；
• 2020 年针对内核代码中的异常处理在不考虑上下文情况下过度保护引发错误的 CCS 论文；
• 2021 年 NDSS 上针对内核内存泄露检测工作新发现了 218 个 bugs（其中 41 个获得 CVE 编号）。

这一系列研究工作持续了多年，发现了海量的安全问题且均得到了顶级会议审稿人的严格审查，其结果的含金量不言而喻。可以这样说，卢康杰教授可能是世界上对 Linux 内核代码中安全问题最了解的人之一！这样一位杰出的安全研究人员，在引发争议的研究工作产生之前已经在这个领域取得了令人瞩目的成绩，所领导的研究团队已经具备了世界级的发现内核安全问题的能力，有那么多问题可以去发掘，难道还需要故意去引入漏洞来证明自己？这让我们想到的 2009 年的一则旧闻：

历史总是惊人的相似，诋毁安全研究人员，制造恐慌是最好的虚假宣传途径。让我们回到本次新闻事件涉及的相关研究工作上来，看看到底事情的真相是什么。

本次事件最初是来自卢康杰教授研究组发表在今年 IEEE Security & Privacy 会议上的研究论文：

这篇论文讨论了一个新型安全威胁——如果攻击者不能直接影响开源软件的代码，他们是否可以通过提交看似合理的补丁的形式来往项目中注入潜在的漏洞？这项研究其实想要回答一个很简单的问题：当很多项目代码的维护者还在依赖人工代码审计的时候，他们到底有多少把握去排除那些存在安全威胁的代码提交？论文的结论是“对于 Linux 维护者来说，他们仅能排除引入的 UAF 漏洞中的 19%”。可想而知，作为开发人员，看到这个结论是不是立马会暴怒：“你找到这么多我们的 bug，我们早就受够了，你还要制造 bug 来诱使我上当” ？！可是事实上，这正暴露了开发人员在对待安全风险时的基本思维缺陷：试想一下，难道攻击者一定会按照开发人员的假设来出牌吗？开发人员总是假定自己面对的都是善意的交流，而安全研究人员却站在攻击者的角度来想问题。换句话说，安全研究人员是通过一种“模拟罪犯的思维和行为”的模式来预防犯罪啊！面对温和的安全压力测试反而愠怒，代码 bug 和漏洞却一直层出不穷，为什么 Linux 内核社区就不能通过此次事件反省一下，在代码审核的过程中不光针对代码功能，也应该引入更多的安全研究专家和代码安全分析技术来保护开发流程和修补流程呢？

再举个例子，同学们，你们可以去搜索一下下面这篇论文：

如果不是这篇由 MIT 的三名学生用机器生成的论文去进行的“学术钓鱼测试”并被某个学术会议的审稿人一致通过，我们恐怕都不知道，很多学术会议的审稿质量究竟有多低。而你完全可以用同样的逻辑说“审稿人都是义务劳动，凭什么你要用机器生成的论文去浪费审稿人的时间”？既然站在审稿人这个位置上，就要考虑到各种可能出现的情况，并负责任地去解决所有会遇到的问题。类似地，如果你不考虑恶意提交的可能性，在过去、现在和未来的任何一个时刻都可能会有真正的恶意攻击者去精心提交有问题的补丁来构造攻击。事实上，这样的例子上真实存在，且背后的主谋是大名鼎鼎的 NSA：它往 NIST 2007 年发布的确定性随机数产生器推荐标准 SP800-90 修订版中引入了一个有问题的随机数发生器 Dual_EC_DRBG，若不是在 4 个月后 Crypto 2007 会议上由安全研究人员 Dan Shumow 和 Niels Ferguson 发表的报告中指出其中的问题，恐怕现在 NSA 监控的手脚又伸得更长了吧？！

其次，在诸多新闻报道甚至很多专业人士的评论中，我们发现了海量的谬误说法甚至是误导，让大家以为卢康杰教授研究团队在“蓄意引入漏洞”，而实际情况根本不是这样！比如下面这个评论

这个贴子看上去很合理，实际上和贴大字报并没有什么区别，因为“往 Linux Kernel 里面提交了 200 多个有 bug 的假代码”完全是道听途说的传谣信谣。卢康杰教授证实过，首先，他们在 S&P 论文的研究过程中根本没有提交过任何真正有漏洞的代码，只有 3 个实验性的有问题的 PoC 补丁，不会引入实质性威胁，且当这些测试被内核社区确认之后，他们就立即中止修补流程并通知相关审核者，保证了安全性不会遭到破坏，也没有给内核维护人员增加太多的负担（如果你连 3 个潜在有问题的代码审核都觉得费时间，那么是不是该假定任何提交都不会有问题而干脆取消代码审核呢？）；其次，所谓“200 多个假代码”其实包括了卢教授研究团队此前提交过的大量有效补丁（我们前面在介绍卢教授研究工作时也提到过），涉及内核中由开发者引入、真实存在的安全问题，对内核安全增强有极大帮助，可内核社区的维护者们以 2021 年 4 月卢教授团队的一些新提交补丁存在问题为名，干脆实施了连坐政策（没错，现在是 2021 年，人类文明已经进入到了信息时代），一股脑将此前提交的这些补丁都撤销了，我们可以想象一下，在长期被研究人员发现问题之后，终于等到一次对方提交的问题不是那么高质量，于是借机就把对方此前所有的工作全部否定，这可是真正的“恼羞成怒”吧？

事实上，过去的 20 年里安全研究会议上发表了大量安全攻击的相关论文，找到了各类系统中不计其数的安全问题，而这些研究不仅没有毁灭这个世界，反而极大推动了计算机系统安全的进步。反过来，我们可以看另一个极端的例子，在 2013 年 Usenix Security 会议上，研究人员发表了一篇论文，介绍了他们突破奥迪、保时捷、宾利和兰博基尼等大众汽车集团旗下豪华车品牌的 Megamos Crypto 防护系统的研究工作，然而大众集团竟然诉诸英国高等法院，请求发布暂时性禁令，阻止三名专家发表论文。然而后面发生的事情我们也都知道，2015 年 9 月大众“排放门”丑闻爆发，该集团在全球范围内为 1100 万辆汽车安装了“减效装置”，使车辆在监管测试中比在实际驾驶环境中看起来污染更少。这和他们对待安全问题的态度倒是保持得非常一致啊（值得一提的是，2013 年的研究论文终于在 2015 年 8 月的 Usenix Security 会议上得到解禁！）

我们发现，还有一些意见甚至认为卢康杰教授应该为这些研究工作表达“愧疚”，恐怕是对安全研究人员日常工作的无知。大家都知道国内外各大 IT 公司都有专门的安全应急响应中心，并且对安全研究人员提交漏洞这件事提供了赏金，对安全研究人员帮助他们的产品提高安全性表示感谢，而不是动辄站在道德制高点上谴责对方。实际上，如果不是安全研究人员而是真正的攻击者发现了这些漏洞并展开攻击，你觉得后果会只是在邮件里面吵吵架这么简单吗？如果大家对安全研究人员在工作中所保持的这种攻击者思维模式感到不解，强烈建议大家去阅读著名的安全专家 Niels Ferguson 和 Bruce Schneier 等所写的《Cryptography Engineering》这本书，其中第一章就很好地介绍了作为安全专家应该怎么样去思考问题：

从另一个侧面来说，开发人员对安全问题的漠视，其实也是安全研究人员逼不得已，不得不通过进行一些模拟安全攻击来证实自己的分析确实有效的原因。为了逼迫开发人员重视安全，一个真正“过分”的安全研究团队——Google Project Zero 安全团队，在保护用户方面，可以说是发起狠来连自己人都打，他们不仅经常公开微软的安全漏洞倒逼微软尽快修复问题，甚至连自家政府的黑客行动也被他们曝光。做出了这样的安全研究工作，美国政府是不是要把研究人员都投到监狱里去呢？

最后，我们想说，那些自媒体新闻还真的挺有影响力的，例如前面提到他们杜撰的“Linus Torvalds 应该要气炸了”，Linus 本人可能是在阅读了国内诸多自媒体之后才知道自己气炸了，于是出来审核了卢康杰教授研究组被撤回的 200 多个补丁，并发现里面大部分都是有效的，没有任何恶意漏洞，亲自发表了评论。看来对于撤回补丁这件事，他是最终真的“气炸了”

文中图片素材均来自网络，题图来自 pixabay。

参考文献：

• [1] Lu, K., Walter, M. T., Pfaff, D., Nümberger, S., Lee, W., & Backes, M. (2017, February). Unleashing Use-Before-Initialization Vulnerabilities in the Linux Kernel Using Targeted Stack Spraying. In NDSS.
• [2] Xu, M., Qian, C., Lu, K., Backes, M., & Kim, T. (2018, May). Precise and scalable detection of double-fetch bugs in OS kernels. In 2018 IEEE Symposium on Security and Privacy (SP) (pp. 661-678). IEEE.
• [3] Wang, W., Lu, K., & Yew, P. C. (2018, October). Check it again: Detecting lacking-recheck bugs in os kernels. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (pp. 1899-1913).
• [4] Lu, K., Pakki, A., & Wu, Q. (2019). Detecting missing-check bugs via semantic-and context-aware criticalness and constraints inferences. In 28th {USENIX} Security Symposium ({USENIX} Security 19) (pp. 1769-1786).
• [5] Pakki, A., & Lu, K. (2020, October). Exaggerated Error Handling Hurts! An In-Depth Study and Context-Aware Detection. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (pp. 1203-1218).
• [6] Emamdoost, N., Wu, Q., Lu, K., & McCamant, S. Detecting Kernel Memory Leaks in Specialized Modules with Ownership Reasoning.
• [7] Stribling, J., Aguayo, D., & Krohn, M. (2005). Rooter: A methodology for the typical unification of access points and redundancy. Journal of Irreproducible Results, 49(3), 5.
• [8] Verdult, R., Garcia, F. D., & Ege, B. (2015). Dismantling megamos crypto: Wirelessly lockpicking a vehicle immobilizer. In Supplement to the Proceedings of 22nd {USENIX} Security Symposium (Supplement to {USENIX} Security 15) (pp. 703-718).
• [9] Ferguson, N., Schneier, B., & Kohno, T. (2010). Cryptography engineering. Design Princi.

本文转载自微信公众号“安全研究GoSSIP”，如需转载请进入公众号联系相关人员