作者 | 褚杏娟
近日，不少开发者（https://v2ex.com/t/840562#reply11）在使用到 vue -cli 中的 node-ipc 模块时，这个依赖项会在桌面以及其他位置创建一个叫做“WITH-LOVE-FROM-AMERICA.txt”的文件，不过打开这个文件是空的。据悉，该 package 每周下载量达到了百万。另外，使用 Yarn 的开发者也受到了影响。
以反战为名的供应链投毒？
开始有人以为只是个恶作剧，但事情并非如此简单。有开发者在对代码进行测试处理后发现，node-ipc 包的作者 RIAEvangelist 在投毒。他起初提交的是一段恶意攻击代码：如果主机的 IP 地址来自俄罗斯或白俄罗斯，该代码将对其文件进行攻击，将文件全部替换成 ❤。该作者是个反战人士，还特意新建了一个 peacenotwar 仓库来宣传他的反战理念。
攻击源代码地址：https://github.com/RIAEvangelist/node-ipc/blob/847047cf7f81ab08352038b2204f0e7633449580/dao/ssl-geospec.js
TC39 代表、Web 开发工程师贺师俊在知乎上分析称（https://www.zhihu.com/question/522144107/answer/2391166752），源码经过压缩，并简单地将一些关键字符串进行了 base64 编码，目的是利用第三方服务探测用户 IP，针对俄罗斯和白俄罗斯 IP 尝试覆盖当前目录、父目录和根目录的所有文件。
虽然作者删除了该段代码，但贺师俊认为这仍然是一种恶劣的供应链投毒。“这里，具体的动机不重要，无论其动机多么良好（更不用说，很多人可能并不同意其政治倾向和道德立场），这样的行为都严重破坏了开源生态中的信任。”
OpenHarmony 项目群工作委员会执行总监、中国科学院软件研究所高级工程师罗未也表示，开源软件供应链安全是一个及其严酷的议题，如果说 log4j 还能看做难以避免的工程误差，这件事就存在违法嫌疑。
有开发者提供了该问题的解决方式：首先按照 readme 正常 install，构建结束后，用编辑器全局搜索'peacenotwar'，将其全部删除；然后在项目的 node_models 目录下，将'peacenotwar'目录删除；之后将'项目 /node_modules/node-ipc/node-ipc.js'这个文件中引用'peacenotwar'的代码注释掉，便可以正常启动项目。
此外，Vue-cli 昨天发布了新版本 5.0.2（https://github.com/vuejs/vue-cli/blob/dev/CHANGELOG.md），将 node-ipc 版本锁定到 v9.2.1，用户可以直接升级。据悉，受恶意代码受影响的 node-ipc 版本为 v10.1.3 ，已经被作者删除或被 NPM 撤下，而 WITH-LOVE-FROM-AMERICA.txt 文件是由 v11.0.0 版本引入的。
在此次事件中，有开发者认为（https://github.com/vuejs/vue-cli/issues/7054） Vue 团队在发布新版本方面做得还不够，Vue 团队应该在官方网站上添加关于该事件的弹出窗口，弃用所有受感染的 vue-cli 包，为其添加一条消息。另外还可以在发布新版本时添加一些警告，以便用户看到警告并自动升级。
脆弱的 Node.js 生态
这一事件再次显示了 JS/Node/NPM 生态的脆弱。
去年 10 月，NPM 官方仓库 ua-parser-js 被恶意劫持，多个版本被植入了挖矿脚本。这个库每周下载数百万次，被用于一千多个项目，包括 Facebook、微软、亚马逊、Instagram、谷歌、Slack、Mozilla、Discord、Elastic、Intuit、Reddit 等公司的项目。同年 2 月，NPM 遭遇供应链投毒攻击，其官方仓库被上传了 radar-cms 恶意包，借此窃取 K8s 集群凭证。
NPM 模块备受开发人员欢迎，这些模块间还普遍存在复杂的依赖关系，某个包通常安装另一个包作为依赖项，而开发人员对此却并不知情。依赖项的绝对数量也带来了更多的安全问题。只要破坏了开发人员普遍使用的流行包，恶意代码可以直接大规模地传播给受害者，而这完全可以通过依赖混淆、劫持弱凭据、利用漏洞访问目标代码或使用开发人员放弃的包的名称来完成。
另外，NPM 存储库 npmjs.com 不要求 NPM 包中的代码与链接的 GitHub 存储库中的代码相同。这意味着攻击者不需要破坏 GitHub 存储库，只要破坏 NPM 包即可。
贺师俊在知乎上表示，要解决或缓解这一问题，应该考虑在 JS 语言和 JS 运行时层面引入一些机制，比如说针对包级别的权限管理（deno 那样粗粒度的应用级别的权限管理并不足以解决供应链投毒问题）、在更多的 API 中引入类似 TrustedType 的机制等。“而这显然已经超出了库、框架或工程管控的层面。这也是为什么我一直说国内头部大厂应该要投入资源去参与语言标准、引擎和平台实现。”
罗未提出，开源软件可参照其他行业的处理方式，如建筑设计师要终生为建筑设计质量担责、银行批贷员要终生为发放的贷款担责等。
“开源软件，特别是重要的核心开源软件，往往远比一笔贷款或一个建筑对全球社会经济影响深远。开源软件作为一个具有风险的重型工程行业，必须匹配的行业风险管控体系，这是我们不得不面对的问题。”
结束语
“看一遍开源协议，要么 fork 要么忍着。”有开发人员对该事件评论道。前有 Node、React、pytorch、GitHub 等官网声明支援乌克兰，后有个人开发者进行供应链投毒，战争让大家对开源有了不同以往的认识。
开源组织应不应该旗帜鲜明地表达自己技术之外的立场，并利用自身影响力去支持某一方呢？这是一个仁者见仁、智者见智的问题，我们不做赘述。但这个问题实实在在地出现了，就成了整个开源行业应该考虑的问题：当开源开始“站队”时，开发者该如何自处？
END
