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