Homebrew存在大漏洞，惡意代碼遠程操縱電腦
本文經(jīng)AI新媒體量子位（公眾號ID:QbitAI）授權(quán)轉(zhuǎn)載，轉(zhuǎn)載請聯(lián)系出處。
Mac包管理工具Homebrew出現(xiàn)了一個大漏洞：
在Homebrew/homebrew-cask倉庫中，通過混淆Homebrew項目中自動拉取請求審閱腳本中使用的庫，可以合并惡意的拉取請求。
如果被濫用，攻擊者可以在使用brew的計算機上執(zhí)行任意Ruby代碼！
該漏洞的威脅登記在國內(nèi)被360CERT評為10分嚴重。
漏洞的發(fā)現(xiàn)者是一位來自日本的后端程序員。
當天下午，他“閑來無事”逛起了HackerOne（漏洞賞金平臺）。順便看看經(jīng)常使用的Homebrew有沒有什么漏洞。
diff檢查邏輯存在缺陷
由于Homebrew項目使用GitHub Actions運行CI腳本，小哥查看了.git-hub/workflows/下每個倉庫的目錄。
其中兩個目錄：一個負責檢查用戶提交的拉取請求的內(nèi)容，進行批準，另一個目錄負責自動合并這些被批準的代碼。
拉取請求的內(nèi)容被fetch后會被改為diff文件，并使用git_diff對其進行解析。
小哥一開始檢查了可以通過批準請求的幾個條件，沒有發(fā)現(xiàn)問題。
但是直覺作怪，他還是掉過頭去二次研究了git_diff倉庫。
當看到其中報告了一個“更改行數(shù)引發(fā)解析錯誤”的問題時，小哥“靈機一動”：
我是不是能以某種方式對拉取請求進行偽裝來滿足批準條件，騙過git_diff？
于是他分析了git_diff解析diff文件的步驟，乍一看沒毛病，但是細看其中一步發(fā)現(xiàn)了“貓膩”：可以多次更改源/目標文件路徑信息。
于是通過下面這兩行代碼：
- ++ "b/#{私藏代碼寫這兒}"
- ++ b/Casks/cask.rb
第一行將私藏代碼以上面的格式嵌入拉取請求，就可以被視為文件路徑信息，而非代碼變動。
第二行為更改文件路徑的必需條件。
這樣就可以繞過必需條件，將含有惡意代碼的拉取請求視為零行更改的
“無害”請求，最終騙過diff，獲得批準，完成自動合并！開始搞事情！
添加“打印日志”操作來驗證此漏洞
“今天的收獲可不菲”，小哥立即行動，提交了一個PR，通過Homebrew搞起了破壞，在HackerOne上對此漏洞進行PoC演示。
以下是具體代碼：
（選取在GitHub上無意發(fā)布了一個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四個變量，才不會在第二行引發(fā)未定義錯誤，這樣就可以作為有效的Ruby腳本執(zhí)行。
通過添加這兩行更改，GitHub返回以下差異：
- diff --git a/Casks/iterm2.rb b/Casks/iterm2.rb
- index 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行更改的請求。
由于既不能修改未經(jīng)授權(quán)使用的cask，也沒有在homebrew-cask倉庫中找到一個測試cask，小哥給Homebrew發(fā)郵件求助，按照工作人員的意思添加“打印日志”這一無害修改來驗證了這個漏洞。
當其他用戶執(zhí)行brew search/brew cleanup等命令時即使沒有安裝目標cask，也將執(zhí)行惡意代碼。
官方在3小時之內(nèi)完成了主要修復，并發(fā)布了通報。
“這不是單方面的責任”
針對這次大漏洞，網(wǎng)友們議論紛紛，有人表示：
如果不是使用ruby解析git_diff，而是使用libgit，這個漏洞就不會發(fā)生。
如果Apple提供了一個功能更強大的軟件包管理器，這不會發(fā)生。
如果數(shù)以百萬計的Homebrew用戶給了他們建造如此龐大的項目所需資金的一小部分，這也不會發(fā)生。
此漏洞沒有單一負責方。
另外，細心的朋友可能還記得，我們此前曾報道了一篇關于黑客用GitHub服務器挖礦的新聞，里面的黑客也是只需提交Pull Request，即使項目管理者沒有批準，惡意挖礦代碼依然能夠執(zhí)行。
和這次這個漏洞一樣，都是抓住了GitHub Actions的自動執(zhí)行工作流功能來“鉆空”。
針對濫用Actions的問題，GitHub近日也更新了幫助保護維護者的新功能，比如在任何Actions工作流運行之前，來自首次貢獻者的Pull Request將需要**具有寫訪問權(quán)限的倉庫協(xié)作者的手動批準**。
