Mac包管理工具Homebrew出現(xiàn)了一個大漏洞：

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

如果被濫用，攻擊者可以在使用brew的計算機上執(zhí)行任意Ruby代碼！

該漏洞的威脅登記在國內(nèi)被360CERT評為10分嚴(yán)重。

漏洞的發(fā)現(xiàn)者是一位來自日本的后端程序員。

當(dāng)天下午，他“閑來無事”逛起了HackerOne（漏洞賞金平臺）。順便看看經(jīng)常使用的Homebrew有沒有什么漏洞。

diff檢查邏輯存在缺陷

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

其中兩個目錄：一個負(fù)責(zé)檢查用戶提交的拉取請求的內(nèi)容，進行批準(zhǔn)，另一個目錄負(fù)責(zé)自動合并這些被批準(zhǔn)的代碼。

拉取請求的內(nèi)容被fetch后會被改為diff文件，并使用git_diff對其進行解析。

小哥一開始檢查了可以通過批準(zhǔn)請求的幾個條件，沒有發(fā)現(xiàn)問題。

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

當(dāng)看到其中報告了一個“更改行數(shù)引發(fā)解析錯誤”的問題時，小哥“靈機一動”：

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

于是他分析了git_diff解析diff文件的步驟，乍一看沒毛病，但是細(xì)看其中一步發(fā)現(xiàn)了“貓膩”：可以多次更改源/目標(biāo)文件路徑信息。

于是通過下面這兩行代碼：

++?"b/#{私藏代碼寫這兒}"
++?b/Casks/cask.rb

第一行將私藏代碼以上面的格式嵌入拉取請求，就可以被視為文件路徑信息，而非代碼變動。

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

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

“無害”請求，最終騙過diff，獲得批準(zhǔn)，完成自動合并！開始搞事情！

添加“打印日志”操作來驗證此漏洞

“今天的收獲可不菲”，小哥立即行動，提交了一個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ā)郵件求助，按照工作人員的意思添加“打印日志”這一無害修改來驗證了這個漏洞。

當(dāng)其他用戶執(zhí)行brew search/brew cleanup等命令時即使沒有安裝目標(biāo)cask，也將執(zhí)行惡意代碼。

官方在3小時之內(nèi)完成了主要修復(fù)，并發(fā)布了通報。

“這不是單方面的責(zé)任”

針對這次大漏洞，網(wǎng)友們議論紛紛，有人表示：

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

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

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

此漏洞沒有單一負(fù)責(zé)方。

另外，細(xì)心的朋友可能還記得，我們此前曾報道了一篇關(guān)于黑客用GitHub服務(wù)器挖礦的新聞，里面的黑客也是只需提交Pull Request，即使項目管理者沒有批準(zhǔn)，惡意挖礦代碼依然能夠執(zhí)行。

和這次這個漏洞一樣，都是抓住了GitHub Actions的自動執(zhí)行工作流功能來“鉆空”。

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

參考鏈接：
[1]https://blog.ryotak.me/post/homebrew-security-incident-en/
[2]https://news.ycombinator.com/item?id=26922448
[3]https://brew.sh/2021/04/21/security-incident-disclosure/
[4]https://wangzhan.#/774.html
[5]https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/