以反戰為名，百萬周下載下傳量node-ipc包作者進行供應鍊投毒

作者 | 褚杏娟

近日，不少開發者（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 等官網聲明支援烏克蘭，後有個人開發者進行供應鍊投毒，戰争讓大家對開源有了不同以往的認識。

開源組織應不應該旗幟鮮明地表達自己技術之外的立場，并利用自身影響力去支援某一方呢？這是一個仁者見仁、智者見智的問題，我們不做贅述。但這個問題實實在在地出現了，就成了整個開源行業應該考慮的問題：當開源開始“站隊”時，開發者該如何自處？