NPM蠕蟲漏洞披露

npm項目已正式承認其存在一個長期的安全漏洞，該漏洞可能導緻惡意的代碼包可以在開發者系統上随意的運作任意代碼，導緻了第一個npm建立的蠕蟲。在一篇名為“npm無法限制惡意代碼包的行為”的漏洞說明vu319816中，sam saccone描述了建立一個蠕蟲需要的步驟以及怎麼讓它自動傳播。盡管這是在2016年一月被報道出來的，然而從npm倉庫管理初始版本釋出開始，這個問題就已經存在而且被廣泛知曉。

這個問題的根源在于，npm子產品有相關的腳本檔案，它們可以在安裝的時候被npm運作。當子產品從npm上被下載下傳後，它有足夠多的機會可以運作其代碼：

preinstall - 在包被安裝之前運作 postinstall - 在包被安裝之後運作 preinstall - 在包被解除安裝之前運作 uninstall - 在包被解除安裝時運作 postuninstall - 在包被解除安裝之後運作

這些腳本使得npm子產品的釋出更加簡單并可以在使用之前進行内容的後期處理。舉例來說，一些子產品原本是由coffeescript或者typescript編寫的，它們需要一個轉化的步驟，或者是用es6編寫的，需要babel轉化後才能運作在目前的浏覽器上。另外，javascript庫一般都會進行壓縮（使其更小），這往往也是需要自動化運作的一個步驟。因為javascript是解釋性的，像make這樣的工具不會被使用，是以npm腳本就用來幹這些苦力活。

在子產品被用戶端下載下傳和使用的時候，npm錯誤地使用了這些代碼，不光用來完成編譯時間驗證，還進行用戶端運作。舉例來說，left-pad慘狀（infoq昨日報道）在重新釋出子產品後得到解決；然而，如果像這樣被廣泛使用的子產品（例如true，其功能隻是列印true）有被影響的代碼塊，那麼這樣的代碼運作在成千上萬的機器上也有了可能。

這些代碼滿足了蠕蟲的建立條件，然後這些蠕蟲持續地影響其他的代碼包并依次傳播。npm包開發者使用标準的證書把他們的代碼包（當然是通過npm）釋出到npm目錄。為了加快釋出，他們有可能會登入到該目錄然後一直保持登入狀态，此後任何的代碼包都可以釋出到該目錄。正因如此，一旦一個npm包開發者的機器被攻占，蠕蟲可以掃描其他的代碼包，然後重新釋出它們（通過開發者現有的證書），與此同時，蠕蟲已經被注入到這些剛被感染的包的腳本代碼塊中。

甚至，包管理其自己也執行javascript，這意味着僅僅是解決包的依賴就會導緻任意代碼的執行。這裡有個例子可以最作為該概念的認證，一個代碼包使用變量作為其包名，被發現可以僞裝成任何的包。參考真實的開源精神，該概念認證是mit證書認證:

a="$1" echo '{ "name": "'"$a"'", "version": "2.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo "error: no test specified" && exit 1" }, "author": "", "license": "isc"}' > package.jsonnpm publish

如果一個包開發者下載下傳了此代碼包然後運作了其腳本，那麼之後該包會運作index.js，之後便可以在終端機器上運作任意的代碼。該例子就展示了怎樣運作sudo rm -rf /，顯然這會在沒有任何備份的情況下造成嚴重後果。

npm目錄允許任何人重新規劃一個存在的代碼包，隻需要在他們的空間裡用相同的命名釋出一個新的版本，這使得該問題變得更加複雜。除非開發者特意的寫死他們所依賴的代碼包版本，否則很有可能自動更新到最近的版本并在之後遭受攻擊。

到目前為止npm的回複都相當的軟弱，否認了其對掃描惡意軟體的責任，并指出開發者使用那些子產品受到注入攻擊也是咎由自取。然而整個基礎都被設定成允許所有人擁有自己的包并可以用任何javascript替換這些包；盡管這些腳本可以被排除在外（通過使用using npm install --ignore-scripts 或者npm config set ignore-scripts true），然而還是有機會使用 require('shelljs').exec('rm -rf /')替代javascript檔案的内容，其運作時還是有着破壞性的影響。并且，讓一個npm會話保持登入意味着任何應用，無論是基于nodejs還是其他語言，都可以很容易的在使用者不知曉的情況下以目前使用者的名義釋出腳本。

最近的這些事件表明，随着javascript的以及伺服器端npm使用的快速增長，其被賦予了和javascript語言本身一樣的安全性的考慮。唯一讓人感到驚訝的是，整個事件花費了這麼長的時間才水落石出。

本文轉自d1net（轉載）