最近有消息說 發現了一個嚴重漏洞 包存儲庫 rubygems.org （該漏洞已被歸類在 CVE-2022-29176 下），其中 允許 未經適當授權， 替換別人的包 通過拉取合法包並在其位置上傳另一個具有相同名稱和版本號的文件來在存儲庫中。
有人提到 該漏洞是由於“yank”操作處理程序中的錯誤造成的，它將連字符後面的名稱部分視為平台名稱，這使得可以啟動刪除與名稱部分直到連字符字符匹配的外部包。
特別是 在操作的控制器代碼中 “猛拉”，電話 'find_by!(full_name: "#{rubygem.name}-#{slug}")' 用於搜索包，而“slug”參數被傳遞給包所有者以確定要刪除的版本。
“rails-html”包的所有者可能指定了“sanitizer-1.2.3”而不是“1.2.3”版本，這將導致操作應用於“rails-html-sanitizer-1.2.3”包“從別人。 »
昨天發布了 Rubygems.org 的安全公告。
該公告涉及一個錯誤，該錯誤允許惡意用戶挖掘某些寶石並上傳具有相同名稱、版本號和不同平台的不同文件。
讓我們更深入地看看在提取過程中出了什麼問題。 作為藉口，讓我們想像一個場景，我們創建一個名為“rails-html”的gem，目的是獲得對廣泛使用的“rails-html-sanitizer”gem 的未經授權的訪問。
有人提到 必須滿足三個條件，為了成功利用此漏洞：
- 只能對名稱中帶有連字符的數據包執行攻擊。
- 攻擊者應該能夠放置一個寶石包，其名稱的一部分直到連字符。 例如，如果攻擊是針對“rails-html-sanitizer”包，則攻擊者必須將自己的“rails-html”包放入存儲庫中。
- 受攻擊的包必須是最近 30 天內創建的或 100 天內未更新。
問題 被安全研究員發現 作為 HackerOne 賞金計劃的一部分，用於發現已知開源項目中的安全問題。
問題 5 月 XNUMX 日在 RubyGems.org 上修復 根據開發人員的說法， 尚未發現剝削痕跡 過去 18 個月的日誌中的漏洞。 同時，目前只進行了表面審計，未來計劃進行更深入的審計。
目前，我們認為該漏洞尚未被利用。
當 gem 版本發布或刪除時，RubyGems.org 會向所有 gem 所有者發送一封電子郵件。 我們沒有收到任何來自寶石所有者的支持電子郵件，表明他們的寶石是在未經授權的情況下開采的。
對過去 18 個月中 gem 更改的審計沒有發現惡意使用此漏洞的示例。 對任何可能使用此漏洞的進一步審計發現，在 RubyGems 的歷史中，沒有發現此漏洞被用於未經授權接管 gem 的實例。 我們不能保證它從未發生過，但似乎不太可能。
為了驗證您的項目，建議分析 Gemfile.lock 文件中的操作歷史 惡意活動表現為存在具有相同名稱和版本的更改，或平台更改（例如，當包 xxx-1.2.3 .1.2.3更新為xxx-XNUMX-xxx)。
作為解決方案 防止在持續集成系統或發布項目時欺騙隱藏包， 建議開發者使用 Bundler 使用“-frozen”或“-deployment”選項 確認依賴關係。
最後， 如果您有興趣了解更多信息，您可以在中查看詳細信息 以下鏈接。