审计Ruby生态系统的中央包仓库 - Trail of Bits博客

Ruby Central聘请Trail of Bits对Ruby应用程序的官方包管理系统RubyGems.org完成安全评估和竞争分析。迄今为止下载量超过1840亿次，RubyGems.org是Ruby语言生态系统的关键基础设施。

这是一篇与Ruby Central团队的联合文章；请在此处阅读他们的公告！完整报告包含我们对RubyGems.org安全审计的所有详细发现，可在此处找到。

我们的审查在2024年8月和9月进行了五个工程师周，发现了三十三个问题，包括一个与SMTP邮件程序中可选StartTLS加密相关的高严重性发现，以及一个涉及生产部署缺乏多方批准的中等风险发现。我们还发现了不可立即利用但如果不解决可能复合为更严重漏洞的问题模式；这些包括过于宽泛的IAM权限、角色分离不足以及服务的不必要公共暴露。我们的建议包括对已识别问题的修复和缓解措施，以及实施安全测试工具（如Semgrep、Burp Suite Professional和Ruzzy）的步骤。

本博客探讨了我们的审计、发现和关键要点，这些要点影响每个依赖RubyGems.org获取依赖项的Ruby开发者——从为副项目拉取gem的独立开发者到管理服务数百万用户的关键任务应用程序的企业。

“Trail of Bits对RubyGems.org进行的审计既让我们有信心负责任地维护Ruby打包生态系统，也为我们提供了关键见解，指导我们应在哪些方面投资以将事情提升到下一个水平。” – Samuel Giddins，Ruby Central驻场安全工程师

图1：在RubyGems中挖掘问题

为什么选择RubyGems？

RubyGems.org是Ruby生态系统的中央包仓库，提供与JavaScript的npm或Python的PyPI相同的基本功能。作为Ruby库的官方分发平台，其安全性直接影响数百万应用程序，从小型开源项目到企业系统。

该平台的架构遵循行业最佳实践：基于标准框架和库构建的三层Web应用程序，前端、后端和数据库层之间有清晰的分离。这一坚实基础使我们能够将安全评估重点放在受信任发布和基础设施配置等高风险领域。

审计范围和发现

三名工程师花了五个工程师周审查rubygems.org和rubygems-terraform仓库中的代码。我们的评估涵盖Web应用程序漏洞、基础设施配置、身份验证机制和访问控制。

在审计部分，我们专注于回答几个问题，包括但不限于：

RubyGems是否容易受到常见Web漏洞的影响，如跨站脚本（XSS）、跨站请求伪造（CSRF）、SQL注入（SQLi）和服务器端请求伪造（SSRF）？
攻击者能否绕过RubyGems Web界面中的身份验证？
未经身份验证的用户能否在RubyGems Web界面中执行未经授权的操作？
访问控制是否得到适当执行？
内部和特权API是否针对外部和未经授权的访问进行了加固？
RubyGems是否安全地反序列化不受信任的数据？
密钥是否安全管理和存储？
AWS服务是否安全配置？

我们确定的33个安全问题包括RubyGems电子邮件系统中的高严重性漏洞，该漏洞可能允许拦截潜在敏感电子邮件。RubyGems.org使用Rails的ActionMailer与SendGrid SMTP进行电子邮件传递。当前，config/initializers/sendgrid.rb中的SMTP配置使用enable_starttls_auto: true，该配置尝试通过StartTLS建立加密通信，但如果安全连接失败，则回退到未加密传输。这创建了一个安全漏洞，攻击者位于RubyGems应用程序服务器和SMTP服务器之间，可以通过在初始握手期间剥离StartTLS命令或返回不受支持的错误来执行降级攻击，强制通信回退到未加密通道。

此问题的推荐修复方法是将enable_starttls_auto替换为enable_starttls，该选项强制执行严格的TLS加密，没有回退选项——如果安全传输不可能，电子邮件将根本不会发送。为了长期安全，我们还建议在CI系统中实施action-mailer-insecure-tls Semgrep规则以捕获类似问题。

我们还在代码库中发现了三个有趣的问题：

RubyGems库具有通过将Marshaled数据与gem文件一起存储来实现反序列化利用的功能。此问题不影响RubyGems.org服务本身（因此是信息性的），但它确实为攻击者提供了利用Ruby用户的途径。
最广泛的问题源于将基础设施即代码（IaC）与手动基础设施更改混合。四个发现（TOB-RGM-16、TOB-RGM-20、TOB-RGM-21、TOB-RGM-29）揭示了这种混合方法如何创建安全漏洞。虽然Ruby Central在我们审计开始时已经迁移到完整的IaC，但这些发现突出了组织为什么应完全致力于自动化基础设施管理。
我们还确定了几个SSRF漏洞。虽然这些问题单独严重性低，但它们仍然令人担忧，因为它们在开发过程中容易被忽视且难以正确修复。复杂性来自于需要平衡安全控制与合法功能——简单地阻止请求不可行，但允许它们需要容易出错的仔细验证。

我们的建议强调两层方法：短期修复侧重于立即安全加固（如限制权限、启用MFA要求和删除未使用的资源）和长期战略改进安全实践。长期建议要求自动化，特别是通过Terraform进行资源管理、定期安全审查和集成安全测试工具。

评估RubyGems与其他包管理器

我们的竞争分析侧重于通过将RubyGems与《包仓库安全原则》文档进行比较来评估RubyGems，并稍微强调将RubyGems与其他四个包管理器（PyPI、npm、Go Packages、Cargo）进行比较。我们评估了RubyGems的身份验证和授权机制、命令行工具和一般功能。虽然RubyGems展示了与其他包管理器相当的功能，但我们确定了19个可以改进的特定领域。

图2：基于竞争分析我们改进RubyGems的建议

这些增强将加强RubyGems的受信任发布基础设施并扩展支持的平台，使开发者更安全、更容易地发布和使用Ruby包。

自动化测试：静态分析、动态测试和模糊测试

我们对Ruby Central的多层安全测试方法结合了自动化工具和手动分析。我们使用Semgrep执行静态分析，使我们能够在问题进入生产环境之前捕获不安全cookie配置、不安全反序列化模式和潜在AWS基础设施错误配置等问题。

我们专门为Ruby Central的需求定制了Semgrep规则，并在报告中提供，以便它们可以集成到CI/CD管道中以进行持续安全测试。您可以在我们最近的博客文章中阅读更多关于我们不断扩展的自定义Semgrep规则集的信息。

对于动态分析，我们部署了Burp Suite Professional以主动测试RubyGems的Web界面，重点关注授权问题、SSRF漏洞和API端点安全。关键扩展如Turbo Intruder帮助识别潜在的竞争条件，而Active Scan++发现了更深层次的问题，如盲代码注入漏洞。

对于较低级别的安全问题，我们使用我们的覆盖引导模糊测试器Ruzzy来测试处理不受信任输入的关键组件。我们特别关注WebAuthn功能中使用的CBOR库，其中内存损坏错误可能特别危险。

这一全面的测试武器库现在使Ruby Central的团队拥有工具和知识以：

在开发过程中通过自动化检查捕获安全问题
持续监控新漏洞
测试处理用户输入的关键组件
将安全测试构建到他们的开发工作流程中
随着代码库和相关基础设施的增长扩展他们的安全测试

保护Ruby包

在这次审查中，我们考虑了某些推荐的安全实践（如生产部署的双重批准要求）如何由于开发团队规模等因素而不总是适用。因此，我们提供了替代解决方案（如启用对生产资源的“紧急访问”），同时指出它们的局限性，帮助Ruby Central团队找到可行的解决方案来加固他们的包管理器。我们希望我们的工作将帮助保护数百万依赖Ruby包用于其应用程序的开发者和公司。我们期待再次与Ruby Central团队合作。

如果您有兴趣了解我们如何支持您的项目，请联系我们。

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

RubyGems中央仓库安全审计：关键漏洞与加固策略

Trail of Bits对RubyGems.org进行的安全评估发现33个安全问题，包括SMTP邮件系统的高危漏洞和部署审批流程缺陷。报告提出短期修复和长期自动化安全策略，涵盖静态分析、动态测试和模糊测试等多层防护方案。