最近有消息说 发现了一个严重漏洞 包存储库 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”选项 确认依赖关系。
最后， 如果您有兴趣了解更多有关它的信息，您可以在中查看详细信息 以下链接。