最近宣布，RubyGems.org软件包存储库中发现了一个严重漏洞（该漏洞已编入 CVE-2022-29176），该漏洞允许在未经适当授权的情况下，通过发起撤回（yank）操作，并上传另一个具有相同名称和版本号的文件来替换存储库中其他人的软件包。
据称，该漏洞是由于“yank”操作处理程序中的一个错误造成的，该处理程序将连字符后面的名称部分视为平台名称，从而可以启动删除名称中连字符之前部分匹配的外部软件包的操作。
具体来说，在“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月5日在RubyGems.org上修复。据开发者称，在过去18个月的日志中，他们尚未发现任何利用该漏洞的痕迹。然而，目前仅进行了初步审计，未来计划进行更深入的审计。
目前，我们认为该漏洞尚未被利用。
当 gem 版本发布或删除时，RubyGems.org 会向所有 gem 所有者发送一封电子邮件。 我们没有收到任何来自宝石所有者的支持电子邮件，表明他们的宝石是在未经授权的情况下开采的。
对过去 18 个月中 gem 更改的审计没有发现恶意使用此漏洞的示例。 对任何可能使用此漏洞的进一步审计发现，在 RubyGems 的历史中，没有发现此漏洞被用于未经授权接管 gem 的实例。 我们不能保证它从未发生过，但似乎不太可能。
为了验证您的项目，建议分析 Gemfile.lock 文件中的操作历史 恶意活动表现为存在具有相同名称和版本的更改，或平台更改（例如，当包 xxx-1.2.3 .1.2.3更新为xxx-XNUMX-xxx)。
为了防止在持续集成系统或发布项目时冒充隐藏包，建议开发人员使用带有“--frozen”或“--deployment”选项的Bundler来确认依赖关系。
最后，如果您有兴趣了解更多相关信息，可以点击以下链接查看详情。