开源软件更安全吗?
![开源软件更安全吗?](https://static001.geekbang.org/infoq/3f/3f566c289f6630c1cb7086cfcabcef74.jpeg)
结论
知名压缩软件 xz 被发现有后门,关于开源软件供应链的安全问题,再次引发讨论。显然大家长期以来关心的是两个问题:
开源软件更安全吗?
开源软件更不安全吗?
如果以上都不是,怎么判定一个开源软件的安全性?
我把结论放在开头:
开源没有让软件更安全,也没有让软件更不安全。是否“开源”,与“安全”之间不存在相关性
判断开源软件的安全性应该考察社区的成熟度和规范性。
漏洞的及时修复比预防漏洞披露更重要
Linus's Law
声称开源软件会更安全的一个论据在于 Linus's Law ——“只要有足够多的眼睛关注,任何漏洞都无处隐藏(given enough eyeballs, all bugs are shallow)”。
看上去无懈可击,但是这显然和事实不符。无论是早年的 OpenSSL 心脏出血,还是近期的 Log4j 的漏洞,开源软件的漏洞报告从未停止过,这其中还包括 Apache Struts2 这样”臭名昭著“的开源软件开发框架,如果有人对这几年给 Struts2 擦屁股的码农说 Apache Struts2 是开源软件,他更安全!这人肯定会被当成神经病的。
没有后门?
如果说漏洞主要来自于程序员的能力不足,那后退一步,是否可以认为至少在开源软件里,在足够多眼睛的关注下,后门应该无所隐藏呢?
很遗憾,这几年来至少 3 起事件把最后的这点信任也摧毁了。
Event-Stream 挖矿后门
Event-Stream 是一个 npm 生态中底层的应用库,right9ctrl 与 event-stream 的作者搞好了关系后拿到了项目的所有权,随即给项目植入了挖矿代码。于是一系列的下游项目纷纷躺枪,其中包含著名的 vue-cli 等。
而这个事情的被发现却是很偶然,一个开发者在使用 nodemon(一个 node 监控程序) 的过程中看到了一条 warning:
crypto.createDecipher is deprecated。
正常来说码农都是忽略 warning 的(此处应有狗头),更何论只是一条 api 即将废弃的 warning,但这位开发者较真了,他很好奇为什么一个 node 监控程序的 warning 里会报一个 crypto 的错误呢?由此这个事情才被挖了出来。
令人细思极恐的是,如果不是因为当时恰巧 crypto 变更了 api,说不定这个事情还要继续被隐瞒很久才会被发现。
![](https://static001.geekbang.org/infoq/d8/d8a70b27861091ff2d5dcc55c9a0c786.png)
Ant Design 圣诞彩蛋
Ant Design(Antd)是非常流行的开源 UI 框架。然而 2018 年的圣诞节它是把好多码农吓的不清。开发团队在没有任何特别的情况下,加进去了一个 feature,给它的按钮加了一个圣诞节积雪效果,显然吓坏了许多 2B 项目的客户(或许还有伊斯兰的)。
![](https://static001.geekbang.org/infoq/f7/f7f73cf6bfb994887d9b7a53e12eb003.png)
![](https://static001.geekbang.org/infoq/da/da8a0efa213d6bd71b84a42db9dd5776.png)
xz 远程控制后门
xz 是一个压缩程序包,特别底层的那种,被一系列的各种应用依赖,这里面包含了 systemd。而潜伏者 JiaT75 通过三年来持续为 xz 项目贡献补丁,成为了项目的主要维护者。然后他精心的构造了一个非常隐蔽方式,通过项目的构建脚本以二进制的形式将后门植入,甚至在代码里都看不出任何痕迹。最终的效果是后门绕过了 RSA 签名验证,从而允许任意的远程 sshd 控制访问。
这个事情的发现也非常偶然,一名测试老哥偶然的发现 sshd 占用的 cpu 时间很高,然后他追踪下去想找找哪部分代码比较慢时,发现居然没有对应的符号表——因为后门是通过二进制直接植入的嘛。所以老哥觉得不太对劲,这件事就此曝光。
比 event-stream 事件幸运的在于,植入后门的 xz utils 在 Debain testing 阶段就被发现了,可这样的幸运不知道还能有几次。
眼睛太少了
实际上 Linus's Law 本身是无懈可击的,确实只要有足够多的眼睛关注,任何漏洞和后门都不可能隐藏。问题在于根本不存在足够多的眼睛。引人注目的永远是那些新鲜的,热门的项目,而背后的底层项目往往无人问津。
Event-Stream 和 xz 项目都长期只有一个人维护,后门的潜伏者恰恰是极少数真正愿意贡献代码的”开发者“,OpenSSL 在心脏出血漏洞爆发之前,一直只有 1 名开发者,这都是这些悲剧产生的不可或缺的条件。
event-steam 项目的原作者在事后写了一封公开信给社区,里面打了个比喻说:
我曾经在一家餐厅当洗碗工,但我失策了,我因为工作的太出色被提拔为厨子。时薪只涨了 50 美分但要负责的事情一下做多了很多。我感觉不值得。写一个(像 event-stream 一样)的热门模块就是把这个事情放大一百倍
我之前看到一个帖子说: 每天无数人使用的 netfilter 现在只剩一个人在维护,调试神器 strace 只有一个人维护,每天无数人使用的 bash ,group 内只有 3 个 active member,tcpdump/libpcap 维护组中的一位自我介绍是:
sometimes l work jobs for living,sometimes l contribute pro bono to free and open source software projects, often l do both.
给人一种很孤独的感觉。
Alan Kay 说:
"互联网做得太出色了,以至于很多人把它看作某种像太平洋一样的自然资源,而非人造的。"
某种程度而言,开源软件,特别是那些底层的基础设施也做的太出色了,以至于开发者们也把它当成了一种自然资源,而忘记了他们背后也需要开发者的维护。在这种情况下, 这些几乎被遗忘的代码,又哪来的眼睛去关注,去审计代码的里的安全问题呢?
视线的方向
在另一些项目里,社区非常的火热,大家热火朝天的讨论着项目的功能,应用场景,以及影响使用的各种 bug。可是安全呢?issue 里有多少内容是关于项目的安全审查呢?恐怕是很少的,因为这一点都不 cool。
在 Antd 的事件里,圣诞节彩蛋的代码是在社区所有人的眼睛关注下,合入项目的,可当时又有谁提出质疑了呢?每一个 pr 的 code review,确实能做到每行代码的 review 吗?还是测试用例跑通了没有冲突就可以 merge 了呢?
如果视线的方向根本就不在安全的位置,那有再多的眼睛又有什么用呢?
没有相关性
所以开源软件更不安全吗?当然不是的,开源没有让软件更安全,也没有让软件更不安全。是否“开源”,与“安全”之间不存在相关性。
而如何去判断一个开源软件的安全性,只需要看下闭源的商业软件如何判断安全性就好了。商业软件我们会考察开发商的资质,历史项目的表现和行业内的口碑。那自然的判断开源软件的安全性应该考察社区的成熟度和规范性,草台班子在哪儿都不靠谱。
而如何让开源社区变得更成熟,更规范,有更多的开发者能参与到其中,避免 event-stream, xz 这样的悲剧再次发生,这是真正值得关注的地方。
此外,相较于的预防漏洞的披露(实际上也没啥可预防的,根本不在控制之内),及时的漏洞修复对安全的意义更为重要,开源软件至少在这个方面给予了开发者充分的“自主可控”能力。
信任,但验证
漏洞永远都会存在,有研究表明 96%的商业代码中都包含开源软件,我很惊讶——居然不是接近 100%。在这种情况下审计每一份代码确保它的绝对安全是不可能的。但我们至少应该保持有验证能力——即在漏洞披露时,验证自己是否受此影响,并快速修复避免进一步的损失。
log4j 是在 2022 年爆发的,2023 年时有一份安全研究说在其审计的 11%的代码中,依然发现了容易被攻击的 log4j 版本,而他们之所以存在很可能是因为企业的 IT 根本不知道他们使用的产品依赖了这个组件——特别是混杂在商业产品中时。
知己知彼,方能百战不殆。
以上
参考资料
版权声明: 本文为 InfoQ 作者【冯骐】的原创文章。
原文链接:【http://xie.infoq.cn/article/7b9fe9e64fa38d129c25cd4f2】。
本文遵守【CC BY-SA】协议,转载请保留原文出处及本版权声明。
评论