Homebrew存在大漏洞，惡意程式碼遠端操縱電腦！

Mac包管理工具Homebrew出現了一個大漏洞：

在Homebrew/homebrew-cask倉庫中，通過混淆Homebrew項目中自動拉取請求審閱指令碼中使用的庫，可以合併惡意的拉取請求。

如果被濫用，攻擊者可以在使用brew的計算機上執行任意Ruby程式碼！

該漏洞的威脅登記在國內被360CERT評為10分嚴重。

漏洞的發現者是一位來自日本的後端程式設計師。

當天下午，他「閒來無事」逛起了HackerOne（漏洞賞金平臺）。順便看看經常使用的Homebrew有沒有什麼漏洞。

diff檢查邏輯存在缺陷

由於Homebrew項目使用GitHub Actions運行CI指令碼，小哥查看了.git-hub/workflows/下每個倉庫的目錄。

其中兩個目錄：一個負責檢查使用者提交的拉取請求的內容，進行批准，另一個目錄負責自動合併這些被批准的程式碼。

拉取請求的內容被fetch後會被改為diff檔案，並使用git_diff對其進行解析。

小哥一開始檢查了可以通過批准請求的幾個條件，沒有發現問題。

但是直覺作怪，他還是掉過頭去二次研究了git_diff倉庫。

當看到其中報告了一個「更改行數引發解析錯誤」的問題時，小哥「靈機一動」：

我是不是能以某種方式對拉取請求進行偽裝來滿足批准條件，騙過git_diff？

於是他分析了git_diff解析diff檔案的步驟，乍一看沒毛病，但是細看其中一步發現了「貓膩」：可以多次更改源/目標檔案路徑資訊。

於是通過下面這兩行程式碼：

++ "b/#{私藏程式碼寫這兒}"++ b/Casks/cask.rb第一行將私藏程式碼以上面的格式嵌入拉取請求，就可以被視為檔案路徑資訊，而非程式碼變動。

第二行為更改檔案路徑的必需條件。

這樣就可以繞過必需條件，將含有惡意程式碼的拉取請求視為零行更改的

「無害」請求，最終騙過diff，獲得批准，完成自動合併！開始搞事情！

新增「列印日誌」操作來驗證此漏洞

「今天的收穫可不菲」，小哥立即行動，提交了一個PR，通過Homebrew搞起了破壞，在HackerOne上對此漏洞進行PoC演示。

以下是具體程式碼：

（選取在GitHub上無意釋出了一個API令牌的拉取請求iterm2.rb 進行更改 ）

++ "b/#{puts 'Going to report it - RyotaK (https://hackeorne.com/ryotak)';b = 1;Casks = 1;iterm2 = {};iterm2.define_singleton_method(:rb) do 1 end}"++ b/Casks/iterm2.rb在第一行定義b，Casks，iterm2，iterm2.rb四個變數，才不會在第二行引發未定義錯誤，這樣就可以作為有效的Ruby指令碼執行。

通過新增這兩行更改，GitHub返回以下差異：

diff --git a/Casks/iterm2.rb b/Casks/iterm2.rbindex 3c376126bb1cf9..ba6f4299c1824e 100644--- a/Casks/iterm2.rb+++ b/Casks/iterm2.rb@@ -8,6 +8,8 @@ sha256 "e7403dcc5b08956a1483b5defea3b75fb81c3de4345da6000e3ad4a6188b47df" end+++ "b/#{puts 'Going to report it - RyotaK (https://hackeorne.com/ryotak)';b = 1;Casks = 1;iterm2 = {};iterm2.define_singleton_method(:rb) do 1 end}"+++ b/Casks/iterm2.rb url "https://iterm2.com/downloads/stable/iTerm2-#{version.dots_to_underscores}.zip" name "iTerm2" desc "Terminal emulator as alternative to Apple's Terminal app如前面所述，git_diff將匹配的行 +++ 「?b/(.*) 視為檔案路徑資訊，而非新增的行，因此，此差異將被視為進行0行更改的請求。

由於既不能修改未經授權使用的cask，也沒有在homebrew-cask倉庫中找到一個測試cask，小哥給Homebrew發郵件求助，按照工作人員的意思新增「列印日誌」這一無害修改來驗證了這個漏洞。

當其他使用者執行brew search/brew cleanup等命令時即使沒有安裝目標cask，也將執行惡意程式碼。

官方在3小時之內完成了主要修復，併發布了通報。

「這不是單方面的責任」

針對這次大漏洞，網友們議論紛紛，有人表示：

如果不是使用ruby解析git_diff，而是使用libgit，這個漏洞就不會發生。

如果Apple提供了一個功能更強大的軟體包管理器，這不會發生。

如果數以百萬計的Homebrew使用者給了他們建造如此龐大的項目所需資金的一小部分，這也不會發生。

此漏洞沒有單一負責方。

另外，細心的朋友可能還記得，我們此前曾報道了一篇關於黑客用GitHub伺服器挖礦的新聞，裡面的黑客也是隻需提交Pull Request，即使項目管理者沒有批准，惡意挖礦程式碼依然能夠執行。

和這次這個漏洞一樣，都是抓住了GitHub Actions的自動執行工作流功能來「鑽空」。

針對濫用Actions的問題，GitHub近日也更新了幫助保護維護者的新功能，比如在任何Actions工作流運行之前，來自首次貢獻者的Pull Request將需要**具有寫訪問許可權的倉庫協作者的手動批准**。