日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

公告:魔扣目錄網(wǎng)為廣大站長提供免費收錄網(wǎng)站服務(wù),提交前請做好本站友鏈:【 網(wǎng)站目錄:http://www.ylptlb.cn 】, 免友鏈快審服務(wù)(50元/站),

點擊這里在線咨詢客服
新站提交
  • 網(wǎng)站:51998
  • 待審:31
  • 小程序:12
  • 文章:1030137
  • 會員:747

來源:量子位

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

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

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

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

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

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

diff 檢查邏輯存在缺陷

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

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

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

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

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

當(dāng)看到其中報告了一個 " 更改行數(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ā)郵件求助,按照工作人員的意思添加 " 打印日志 " 這一無害修改來驗證了這個漏洞。

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

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

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

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

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

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

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

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

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

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

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

分享到:
標簽:漏洞 小哥 請求 代碼 文件 更改 批準 執(zhí)行
用戶無頭像

網(wǎng)友整理

注冊時間:

網(wǎng)站:5 個   小程序:0 個  文章:12 篇

  • 51998

    網(wǎng)站

  • 12

    小程序

  • 1030137

    文章

  • 747

    會員

趕快注冊賬號,推廣您的網(wǎng)站吧!
最新入駐小程序

數(shù)獨大挑戰(zhàn)2018-06-03

數(shù)獨一種數(shù)學(xué)游戲,玩家需要根據(jù)9

答題星2018-06-03

您可以通過答題星輕松地創(chuàng)建試卷

全階人生考試2018-06-03

各種考試題,題庫,初中,高中,大學(xué)四六

運動步數(shù)有氧達人2018-06-03

記錄運動步數(shù),積累氧氣值。還可偷

每日養(yǎng)生app2018-06-03

每日養(yǎng)生,天天健康

體育訓(xùn)練成績評定2018-06-03

通用課目體育訓(xùn)練成績評定