[讨论] 如何减少 Xz Backdoor 类似问题的发生
source link: https://www.v2ex.com/t/1028563
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
不知道大家有没有看过这篇帖子关于 xz 被恶意开发者注入，导致 linux 发行版有漏洞，可 ssh 连接用户服务器？🐶 https://boehs.org/node/everything-i-know-about-the-xz-backdoor
今天早上思考了一上午这种 xz 开发者恶意投毒的问题如何解决🤔，目前想到一个方案，去中心化存储，下载别人的发布的系统(例如 linux)需要支付一笔 gas(包含保险费)费，如果有恶意投毒，那么可以要到赔偿，我们将所有知名的项目都开发一条链，允许他们发一些 NFT 等，从而可以赔偿。🐶
这些链的的合约有保险触发机制，当大家投票都认为这个项目是恶意的，那么会自动触发这个项目不停生成 NFT 直到赔偿所有用户的损失，虽然这会导致这个项目的贬值，这样就达到了对开发者约束的目的，从而让他们不得不非常谨慎 review 代码🤔，因为这次 xz 攻击，攻击者看项目方去度假了，以及测试时间不充分。🤔
大家觉得如何？🤔
 |
lonelykid 13 小时 37 分钟前 开源项目本来就是大家自备干粮全凭爱好在做，你整这些没人会跟你玩的。
解决方法也只有加强 review ，有任何疑点都要 commit 方解释清楚，最好引入 AI 审查代码。 |
17 |
yumusb 13 小时 37 分钟前 简单，不升级即可。
|
 |
Dynesshely 13 小时 32 分钟前 不怎么样, 开源本身是不求回报的行为, 如果通过这种方式来约束开发者, 会极大地降低开发者地开发积极性
换句话说, 人家都免费给你用, 出了事情当然你自己负责, 当然, 大家对该项目的信任会大打折扣 我对这个事件的思考是: 我们应该重新思考开源行业中的信任链, 即我们是否应该完全信任第三方的代码 目前整个开源行业都是依靠信任维系的, 大家信任 Linux 发行版的发行商, 所以使用 Linux 发行版; 发行商信任第三方程序, 所以默认包含并依赖这些程序; 第三方程序库作者信任积极贡献者, 所以允许 TA 成为维护者 这就导致这次攻击几乎是非常成功而且影响极大 但鄙人见识浅薄, 并没有想出更好的办法来避免这类攻击事件的再一次出现 (毕竟就算防住维护者, 也不能保证库作者本人不会写出某些 bug 导致出现可被攻击的漏洞 |
 |
yolee599 13 小时 26 分钟前 via Android 那干嘛不直接买商业系统呢？这样还有售后服务，出问题也是卖方负责赔偿
|
 |
xinbaoCode 13 小时 25 分钟前 @lonelykid 如果这样呢，开发者成为有人气的项目后，可以铸造自己的链，这样就解决了开源者难赚钱的问题。而且激励了大家。🤔
|
 |
agagega 13 小时 25 分钟前 via iPhone 不要试图用技术解决人的问题
|
|
xinbaoCode 13 小时 20 分钟前 @xinbaoCode #7
不好意思，刚刚点错了，发布为空 。 1. 对于激励开源，开发者成为有人气的项目后，可以铸造自己的链，这样就解决了开源者难赚钱的问题。而且激励了大家 2. 对于开源行业中的信任链，我们用区块链与信任链绑定，如果大家投票都认为这个项目是恶意的，那么会自动触发这个项目不停生成 NFT 直到赔偿所有用户的损失。这样就更深的加固了信任。 |
 |
james122333 13 小时 14 分钟前 没想到我刚讲 systemd 就有人爆出来了...
要讲的话就是选技术很重要 首先虽然 xz 压缩率高但效能差本身就不是非常好的选择 过於开放的社区副作用也在此 每次看到有人在嫌社区不够开放我都在想是不是想搞事 好的东西自然会考虑合进去 |
 |
yankebupt 13 小时 8 分钟前 二楼是指 LTS/LTSC?
不升级，只升级必要的包，打补丁而不是发新版本……一个版本用 10 年…… 两个问题： 一个是编译脚本被 review 忽视掉了。一般人谁看那个啊 一个是测试用二进制数据并不是真的随机数据而且也没有公布生成用的随机/处理算法导致被挂马 综上应该做一次清查用 AI 扫所有的编译脚本有疑虑的提交人工 review ，然后要求所有直接提供的二进制提供来源或生成算法或签名 头疼医头脚痛医脚 |
 |
ihuotui 12 小时 45 分钟前 0day 没有人发现怎么都没有知道，这些是国家级的行动钱只是数字
|
 |
vcn8yjOogEL 12 小时 43 分钟前 持续审核配合可复现构建, 审核完毕才会进入核心系统仓库
需要快速迭代的用户程序用 SELinux 等技术套沙箱, 尽可能缩小受击面 |
 |
ericFork 12 小时 36 分钟前 为啥什么都要往链上靠
|
 |
GeekGao 12 小时 30 分钟前 技术无法解决人性问题。
要想防安全风险，就要有个负责任的法律实体来兜底，这也是为啥很多国企和政府采购商业公司的产品而非部署开源代码搞平替。 |
 |
Rrrrrr 12 小时 23 分钟前 这不是你要考虑的问题
|
 |
cdlnls 12 小时 22 分钟前 via Android 实名制提交代码，实名制开源，再加上公安局备案机制。手动狗头
|
 |
onion83 12 小时 12 分钟前 楼主玩币玩到魔怔了。。
|
 |
leonshaw 12 小时 8 分钟前 via Android 每个项目一条链，项目崩了还有人给你的链接盘？
|
 |
adoal 12 小时 0 分钟前 这是餐桌上的人玩的游戏。菜单上的化石生死看淡，听天由命吧。
|
 |
skies457 11 小时 55 分钟前 "如果有恶意投毒，那么可以要到赔偿"
呃。。 |
 |
nrtEBH 11 小时 43 分钟前 举着锤子看啥都像钉子 你们 b 圈那一套就别硬凑上来吧
开源软件本质上都用爱发电的 开源项目的使用者似乎没有什么特别好的办法杜绝这种情况 对于商业项目的 security admin , 从类似事件里学点经验多做点技术加固手段咯 |
 |
gamexg 11 小时 32 分钟前 项目的钱来源是 用户付的费用,然后赔偿就是这个费用?
那么意味着出问题时赔偿是当时付的使用费? 另外如果项目出现这种恶意 bug,那么这个项目的虚拟币是不是会直接暴跌? 赔付的虚拟币还有意义吗? 我看有说法是投毒人为项目贡献了 2 年代码,才干的投毒. 有这个毅力,我是觉得别指望常规手段能够防的住, 甚至我可以说,有这个能力/精力,即使是商业公司项目一样能做到投毒. 而且可能比开源项目还难以发现问题. |
 |
wweerrgtc 11 小时 18 分钟前 via iPhone 我用过开源软件 但我没玩过虚拟货币
|
 |
mikewang 11 小时 13 分钟前 这次其实还好，不是还没有正式发行版受影响嘛。
开源就是这样的，投毒难免，需要有人检查测试。这次就是 postgres 的一个贡献者在测试过程中发现的。 以 Debian 为例，需要经过 Unstable -> Testing -> Stable 虽然上游已经 release 了，但是还是需要社区在 Testing 阶段做各种测试。 在 Stable 之前拦截住都算可控，不过这次事件确实很恶劣。 |
 |
HUZHUANGZHUANG 11 小时 7 分钟前 小孩子杀人怎么解决？ 解决不了，这是人性问题，不是法律不给力
|
 |
hello2090 11 小时 1 分钟前 你这完全是把基于信任的一个系统改成一个默认人人都是罪犯的系统啊
|
 |
levelworm 11 小时 1 分钟前 via Android 大厂不肯出钱，那就没办法了。
|
 |
XIVN1987 10 小时 25 分钟前 解决方法就是别用免费软件，，只用超级大公司巨贵的软件，，这样出了问题可以通过诉讼获得巨额赔偿，，大公司就有巨大的动力保证软件的安全，，
既想免费白嫖，，还想出了问题让人赔偿，，天下哪有这样的好事儿。。 |
 |
0o0O0o0O0o 10 小时 21 分钟前 via iPhone @levelworm #29 不但不肯出钱。还有巨头集成了开源软件后，用户遇到了问题找客服，客服让用户去找开源项目寻求解决方案。以及 https://pigsty.cc/zh/blog/db/redis-oss/
|
 |
OldCarMan 9 小时 50 分钟前 之前我提过类似的问题，可以参考下：
https://www.v2ex.com/t/920810 不过个人觉得，可能对于大部分人，只是看看相关的库在开源社区的数据表现，以此作为使用的判断条件，有时间和能力当然在使用前 review 一下最好，反之，如果有这个担心，可以先在隔离环境先跑一下，观察存不存在使用异常，或者做好环境监测，尽量做到快速反馈和现场保护。 |
 |
cosette 8 小时 51 分钟前 保险可以一定程度上分散风险造成的损失，但不能规避风险，同样的，也不能阻止风险的扩散，风险本质是不可预知的。
保险公司依然知道需要精巧的设计所需分担的风险的种类，近可能将其限制在一个狭窄的范围，即便如此保险公司依然不可能给自己买保险，遇到意料之外的情况，也只能破产。 而软件工程是风险最具有扩散性的地方，大量的项目互相交错依赖，层层叠叠，你甚至不知道你所依赖的某个项目究竟是谁在提交代码。这里是信任不应该发生的地方，而你能做得也只有信任，你只能相信开发者是有道德感的，同时还有大量的人在做 review ，同样富有道德感，并且有足够的能力和精力发现问题。 没有任何出于理性的方案能够防范这种原初风险，正如没有任何理性的兜底方案能够创造出美好无痛的生活。 |
 |
shinyzhu 8 小时 16 分钟前 看到 gas 就知道你们爱搬出那一套机制来保护数据咯保护所有权咯，扯淡，除了你们炒作的那些空气之外没有任何价值。
|
 |
hez2010 6 小时 52 分钟前 via Android 其实今天几乎所有主流的开源软件背后都是大厂在主导，哪怕是 Linux ，大多数代码也都来自各商业厂商为了添加对自己产品的支持才有的所谓的贡献，理想中的自由的开源世界早已经名存实亡了。
|
|
yankebupt 6 小时 13 分钟前 一定要不靠 review 靠事后处罚么？有点晚，不过也可以讲讲
楼主这个方法，用非链上的方法讲，就是数字签名保证制度 几个人数字签名保证一个新人入伙，他的数字签名才有效，如果这个新人是贼，上溯下挖好几级，数字签名全部作废，这些人签的包全都不再被系统信任，想重新入伙？看谁愿意保你吧。你看 PT 不是在用么，比签名简陋点，什么邀请码…… 用旧时的术语讲就是保甲连坐制。后来为什么没了？一个人也能造反，指不定谁造反，造反的诱惑大上天，把项目 NFT 赔干净了也没有在*几乎所有*主流发行版放一个任意 ssh 级别漏洞的利益大，没人愿意互相保了啊。（狗头 |
 |
moudy 4 小时 45 分钟前 这个问题显然是质量控制体系有漏洞。如果有相关的固定场景功能测试，就能在第一时间发现基础功能没 enable 。与其纠结代码是否可信，不如强化项目规则，相关 feature 都得有 negative test
|
 |
mizuhashi 3 小时 3 分钟前 https://www.solidot.org/story?sid=77741
Solidot: xz 后门事件凸显了维护者在维护一个基本上不会得到多少外界帮助的开源项目时所面临的挑战，当别有用心的人热情提供帮助，你真的难以分辨对方是真心还是假意。对于 xz 项目原唯一维护者 Lasse Collin 邮件列表交流的分析显示，这位维护者早就筋疲力尽了，他承认如果有 bug 会去修，但开发新功能基本上不可能了。这种情况在 JiaT75(Jia Tan)积极提供帮助后发生了变化，Jia Tan 是少数或者可能是唯一一位愿意“帮助”而不是抱怨开发停滞的人。Lasse Collin 表示考虑让 Jia Tan 扮演更重要的角色，甚至让其接手维护。对于不断抱怨和提出要求的用户，他强调这是一个无薪水的业余项目。在“用户”不断的要求之下，Jia Tan 成为了项目的共同维护者。 |
 |
cnt2ex 2 小时 12 分钟前 @yankebupt #37
各大发行版的官方包维护者已经是类似的机制了。要成为官方的包维护者，必须要得到一个甚至多个 sponsor 的支持才能让你加入。 然而这套方案在开发者身上显然不适用，开发者并没有必要非要让某个软件加入到你信任关系里。更直白一点就是，我写的代码你爱用不用，我又没求你用干嘛还要申请入伙。 这次的问题是，各大发行版的包维护者都无条件地信任了上游的代码，导致带后门的包进入了官方仓库，还好在进入 stable 之前被人发现了，从而限制了影响范围。 真要说解决这类问题的方案，估计也就只能增加包维护者的责任了。但实际上，很多包维护者和开源软件作者一样，本来就是志愿工作。以前成为了某个包的维护者，但是现在没太多精力 review 代码，导致后门悄悄溜进了下游。 |
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK