發表日期 3/16/2022, 4:25:11 PM
作者 | 褚杏娟
近日,不少開發者(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 等官網聲明支援烏剋蘭,後有個人開發者進行供應鏈投毒,戰爭讓大傢對開源有瞭不同以往的認識。
開源組織應不應該旗幟鮮明地錶達自己技術之外的立場,並利用自身影響力去支持某一方呢?這是一個仁者見仁、智者見智的問題,我們不做贅述。但這個問題實實在在地齣現瞭,就成瞭整個開源行業應該考慮的問題:當開源開始“站隊”時,開發者該如何自處?