RubyGems 是一个软件包注册核心，用于为 Ruby 语言生态系统提供软件，它托管超过 170,000 个 Ruby 包 (gem)，在其生命周期内提供了近 1000 亿次下载。
2022 年 5 月 6 日，RubyGems 披露存在一个可导致未受权拜访的破绽（CVE-2022-29176），该破绽的 CVSS 评分为 9.9。
RubyGems 公布平安布告指出，“因为 yank 操作中存在一个破绽，因而任何 RubyGems.org 用户都能越权删除并取代某些 gems。”
本篇文章将剖析 CVE-2022-29176 破绽的性质，带来的影响评估和事件剖析。
想要自动检测恶意软件？分割 Mend 受权合作伙伴——龙智，理解更多对于 Mend 的主动恶意软件检测平台 Diffend 的信息。
2022 年 5 月 6 日，公布了一个 RubyGems 的要害安全漏洞，RubyGems 是 Ruby 生态系统的次要包源。
该破绽是因为可从存储库中勾销公布（“yank”）某些 Ruby 包，并应用雷同的文件名和版本号从新公布净化或歹意的版本。该破绽须要满足以下条件：
- gem 名称中有一个或多个破折号，例如 something-provider。
- 以第一个破折号之前的单词命名的包不存在（例如，用于 kostya-sigar 的 kostya, 用于 googleapis-common-protos-types 的 googleapi）。
- 被篡改的包是在过来 30 天内创立的，或者超过 100 天未更新。
因为 RubyGems 提供了具体的包信息列表，所以很容易通过解决这些信息来找到满足以上条件的包。
此外，咱们不能假如歹意行为者之前没有留神到该破绽。尽管这个破绽是由平安钻研人员报告的，但考察人员也假如已存在利用该破绽的状况。思考到这一点，在查看可疑流动时，咱们从新拜访了 RubyGems 上所有可用的软件包。
CVE-2022-29176 的实质
RubyGems 中的一个 bug 是，它容许未经受权的参与者，在不用成为其所有者的状况下撤回（删除）包版本。该申请将被分派给包的控制者，但因为获取包版本的机制，撤销操作可能将在不同的包上执行。相干代码如下：
find_by!(full_name: "#{rubygem.name}-#{slug}")因为没有正确地过滤 / 查看 slug，所以可能查问到其它包的版本。但尽管如此，它也可能会带来法律和平安危险。
例如，googleapi 示例，能够构建以下的包版本:slug: googleapis-common-protos-types-1.3.1 当发送 common-protos-types-1.3.1 作为一个 slug 时。
这将无效地删除此版本的指标包。
因为这种性质的问题，事态迅速降级。通过删除所有版本，在某些状况下，该名称能够用于复用。这意味着咱们有了一个很棒的新包名可供使用。
包版本的不变性怎么样？
RubyGems 软件包的版本在设计上是不变且不可代替的。这就意味着除非产生安全事件，即有人泄露 RubyGems 并篡改软件包的内容，否则用户不能简略地更换或更新给定的版本。当然，您也能够删除版本或上传新版本，但新版本须要有不同的编号。
补充信息
这里常常被疏忽的一点是，单个 RubyGems 版本仅在公布它的平台范畴内是惟一的。平台基于 CPU 架构、操作系统类型，有时还基于操作系统版本。示例包含“x86-mingw32”或“java”。该平台表明 gem 仅实用于为该平台构建的 ruby。RubyGems 会主动为您的平台下载正确的版本。
默认平台称为 -ruby，它能够在任何平台上运行。尽管您无奈替换它的内容，但您能够自在地删除它并公布具备雷同编号的新平台特定版本。例如，您能够删除 karafka-testing-1.4.3 并上传 karafka-testing-1.4.3-i686-linux。版本自身不会扭转，但会指定平台。
没有什么能阻止歹意行为者列出所有可用平台，并在每个平台公布一个版本，从而导致每名用户均受此影响。
我有一个 Gemfile.lock，它是不可变的，是这样的吗？
当然不对。在某些状况下，只管有锁定文件，Bundler 仍能够从新解决依赖关系。这是一种预期中的行为，但尽管如此，它也可能会带来法律和平安危险。
应用 -frozen 作为默认设置，并应用受损的软件包，您将收到相似于以下内容的音讯：
“您的捆绑包仅反对平台 [“x86_64-linux”]，但您的本地平台是 x86_64-darwin。应用 bundle lock –add-platform x64-mingw32 将以后平台增加到锁文件中，而后重试。”
尽管上述语句不具备描述性，也未说明任何平安危险，但至多它可能会让人们留神到某些事件曾经产生了变动。
在 Bundler 中进行校验和验证会有帮忙吗?
不会。在上述情况下，Bundler 可能会决定从新解析依赖关系。新的依赖关系意味着更新锁文件。更新的 lockfile 意味着针对特定平台的雷同版本的新校验。
影响评估和事件剖析
咱们正在进行一个口头，旨在帮忙开源软件社区和包注册核心爱护所有用户，作为口头的一部分，WhiteSource 提供了来自咱们 Diffend 平台的情报。
当咱们收到对于该事件的告诉时，咱们应用 Diffend 进行了评估，以确保：
- 没有风行的软件包被篡改
- 没有任何包通过该破绽被接管(除了钻研包)
- 没有包公布了特定于平台的版本，同时删除了 -ruby
当剖析这样的案例时，咱们从影响评估开始。因为咱们实时收集对于 RubyGems 的信息，咱们可能查看到，去年有：
- 132045 版本的增加或删除
- 16,629 个包受到这些更改的影响
因为 Diffend 跟踪所有权转换，所以咱们晓得包产生的任何所有权变动。
因为这种攻打须要一个新的所有者，所以咱们能够将范畴放大到 1101 个包。
当惯例的所有权转移产生时，应该有一个阶段，在这个阶段有两个所有者：
- 旧所有者交出包所有权
- 新所有者承受所有权
依据后面探讨的破绽实质，利用该破绽的所有者转移，不存在交接阶段，旧所有者隐没，新所有者呈现。
预期所有权转移流程：
意外的所有权转移流：
留神：这种模式能够有非法的案例，但对咱们来说，该模式能够帮忙咱们筛选异样包。
当将此逻辑利用于咱们的 1,101 个包时，咱们最终会失去 174 个包。当初，过滤了带有连字符的包后，咱们最终剩下 60 个。在这 60 个中，只有三个具备每个平台特定的版本：
- shopify-proxy-2-jit
- mrslave-omniauth-runner
- mygem-dcgl-other
留神：这个问题有更多的概念包可能证实，但这些包没有所有权更改，因而无关紧要。这些软件包都是钻研性质的。
能够必定的是，咱们仔细检查了所有 60 个，没有发现任何歹意签名。
咱们真的能够假如之前没有人留神到这一点吗？
不能够，这就是为什么咱们还查看了所有被撤销了 -ruby 平台版本，同时存在其余平台雷同版本的包。
SELECT versions.package_id from versions
inner join (SELECT "versions"."package_id", "versions"."number" FROM "versions" WHERE yanked_at is not null) yanked
on versions.package_id = yanked.package_id and versions.number = yanked.number
where versions.yanked_at is null这为咱们提供了 85 个包，其中 29 个带有连字符。对于这 29 个包，咱们再次进行了人工审核，没有发现任何歹意斗争的迹象。
当初撤销当前篡改能够吗？
这个也被查看过了。咱们曾经确定了过来两周内被移除的 25 个包，但没有一个包可能引起咱们的留神。
那么“惯例”的篡改案例呢？
尽管这超出了本次考察的范畴，但咱们还监控各种注册表，以发现潜在的包篡改迹象。到目前为止，咱们未在 RubyGems 中发现任何问题，也未表明存在任何问题。最重要的是，咱们也没有发现任何与此事件相干的恶意程序包。
总结
尽管这个问题的确很重大，因为它可能在 Ruby 社区中造成了重大影响，但依据咱们的数据和以下考察，得出的论断是，gem 没有受到侵害并且问题失去了缓解。
Mend 的主动恶意软件检测平台 Diffend，通过查看确保您仅应用通过验证的包源代码，并避免您将任何恶意软件包导入您的组织或集体计算机。
意识作者
马西杰·门菲尔德（MACIEJ MENSFELD）
马西杰·门菲尔德是 Diffend 平台的创始人和高级产品经理。他开发了供应链平安和开源软件。
文章起源：https://www.mend.io/resources…
如需理解更多对于 Mend（原 WhiteSource）的信息，请分割 Mend 受权合作伙伴——龙智：
电话：400-775-5506
邮箱：marketing@shdsd.com