通过OSTIF强化开源基础设施安全
开源技术改进基金(OSTIF)应对开源世界中常被忽视的挑战:当今互联网基础设施所依赖的软件项目,正如OSTIF所言,其所有开发、测试和维护工作“仅由数量惊人地少且时间有限的一群人”承担。
开源社区贡献者时间的稀缺性是一个众所周知的问题,这使得互联网的关键基础设施变得脆弱。引用OSTIF的说法:“由于缺乏利润动机,核心开源项目资金严重不足且资源匮乏。这导致关键互联网基础设施容易受到漏洞、文档不完善、性能低下、发布周期缓慢甚至间谍活动的影响。”
我们完全赞同这一观点。
过去一年,我们很荣幸通过OSTIF与开源项目团队合作,开展威胁建模评估和安全代码审查。我们认为,我们勇于推进安全并应对技术最具挑战性风险的核心使命与OSTIF的目标高度一致。通过与OSTIF的合作,我们为提升开源社区的安全态势做出了重要贡献。本篇博客重点介绍OSTIF委托Trail of Bits进行的一些近期安全评估。
关于我们的工作
在Trail of Bits,我们从事多种类型的安全工作。我们一些更受欢迎的服务包括:由定制模糊测试工具和模糊测试开发驱动的安全代码审查、自定义静态分析规则集以及有针对性的手动审查;涉及架构审查、系统思维和威胁场景开发的威胁建模练习;CI/CD管道加固;以及修复审查。最优情况下,评估会涉及在这些多个领域具有专业知识的工程师。这有助于我们为客户提供最佳的性价比。
有时,我们在一个项目中涉及不同类型的专业知识,例如,为同一客户运行威胁建模练习然后执行代码审查。当我们在威胁建模工作之后进行安全代码审查时,我们的代码审查可以从威胁建模工作产生的设计级发现开始。这意味着我们可以更快地编写针对给定代码库最脆弱区域的模糊测试工具和模糊测试!随后进行修复审查,让我们的安全工程师有机会帮助指导和重新评估基于我们发现的缓解措施。
由于聘请我们的客户范围广泛,客户的期望和要求可能有所不同。在下面将介绍的OSTIF组织的评估中,您将看到这些类型工作的不同组合。其中一些项目既包括威胁建模练习又包括安全代码审查,而其他项目仅专注于代码审查。所有这些项目的共同点是,我们基于项目性质和客户需求制定了定制的安全评估策略。
Linux内核发布签名
Linux内核运行在从普通智能手机到构成网络最广泛使用基础设施的服务器,再到超级计算机的设备上。我们所知的互联网实际上运行在Linux上。Linux开发的一个关键部分是内核发布签名,它允许用户通过密码学验证内核发布的真实性以确保其可信度。
在2021年3月至4月进行的这次审查中,我们领导了与Linux基金会的技术讨论,并检查了他们在内核发布签名过程上的文档。我们的评估包括对签名密钥管理的审计、开发人员的签名工作流程以及签名和验证步骤中涉及的密码算法。
我们的主要建议之一是Linux基金会强制使用智能卡存储私钥,这将防止攻击者在入侵开发人员工作站时能够签署恶意代码。我们还建议Linux基金会采用更广泛的密钥分发方法,以减轻当前托管公钥的git.kernel.org服务器被入侵的风险,用现代且更强大的替代方案如ECDSA和Ed25519替换旧的签名方案如RSA和DSA,并创建关于密钥管理策略的文档以防止签名过程中的错误。
有关我们的发现和建议的更多信息,请参阅OSTIF的项目公告和我们的完整报告。
CloudEvents
CNCF无服务器工作组创建了CloudEvents规范,以一致、可访问和可移植的方式标准化事件声明和传递。它提供了一个标准格式,用于在不同的云提供商和工具集之间共享事件,以及多种编程语言的SDK。
在2022年9月至10月,我们与CloudEvents团队进行了轻量级威胁建模评估,努力识别攻击者可能用于破坏实现该规范的系统的方法。我们的团队随后对JavaScript、Go和C# CloudEvents SDK进行了安全代码审查。对于这个项目,我们结合使用了自动化测试工具、手动分析以及整体架构和设计审查。总共,我们识别了七个问题,包括JavaScript SDK中潜在的跨站脚本以及所有三个SDK的几个易受攻击的依赖项。
我们的最终报告包括这些发现、我们开发的威胁模型、几个代码质量建议以及关于在SDK代码库上使用自动化分析工具的指导。获取所有细节,请参阅OSTIF的项目公告和我们的完整报告。
curl
说curl无处不在都是一种轻描淡写的说法。这个著名的实用程序使用户能够通过多种网络协议传输数据,根据curl网站的数据,其安装量超过200亿次,遍布“汽车、电视机、路由器、打印机、音频设备、移动电话、平板电脑、机顶盒、[和]媒体播放器”。
感谢OSTIF,我们的团队有幸在2022年9月至10月对curl二进制文件和软件库(libcurl)进行了审查。我们以威胁建模评估开始了我们的审计,这是一个关键的练习,加深了我们对curl和libcurl内部组件以及它们如何协同工作的理解。由此产生的威胁模型显著影响了我们审查实际源代码的方法,具体化了我们对curl内部的理解,并帮助我们决定最初针对哪些组件进行模糊测试和安全代码审查。
到代码审查结束时,我们发现了14个问题,包括通过模糊测试识别的两个高严重性内存损坏漏洞,这是我们与手动安全代码审查工作并行进行的。我们帮助扩展了curl的模糊测试覆盖范围,并通过审查结束后继续的模糊测试,发现了几个漏洞,包括CVE-2022-42915、CVE-2022-43552,以及一个最初是随口玩笑的重要发现。查看我们在最终报告中的curl模糊测试覆盖改进和发现。
Kubernetes事件驱动自动缩放(KEDA)
KEDA是Kubernetes容器的自动缩放工具。它内置支持众多“缩放器”,即可以根据从配置的外部源(如AWS SQS、RabbitMQ和Redis Streams)接收的消息触发缩放的接口。KEDA有效管理Kubernetes pod的添加以满足测量需求。
我们在2022年12月以威胁建模练习开始了对KEDA的审查,与KEDA团队一起走查威胁场景。使用威胁模型来指导我们的方法,我们随后进行了代码审查。我们的团队使用自动化测试和手动审查发现了八个发现。在这些发现中,包括未能为与Redis服务器的通信启用传输层安全(TLS),创建了一个攻击者可以利用进行中间人攻击的漏洞。
除了这些发现,我们的最终报告还展示了我们的威胁模型、对KEDA代码库成熟度的评估、我们编写的一个自定义Semgrep规则用于检测我们注意到是代码中模式的一个编码问题,以及旨在帮助KEDA主动增强其整体安全态势的长期建议。更多细节请参考我们的完整报告。
Eclipse Mosquitto
2023年3月,Trail of Bits有机会与Eclipse基金会合作评估Mosquitto项目。Mosquitto包括一个流行的MQTT消息代理和客户端库(libmosquitto)。Mosquitto有广泛的应用,从家庭自动化到生物信息学再到英国的铁路信号基础设施。
在这个分为两部分的项目中,我们开发了一个威胁模型,然后对代理应用程序、libmosquitto以及相关的命令行工具(例如mosquitto_passwd)进行了安全代码审查。我们的威胁模型识别了架构级弱点,例如代理中缺乏可配置的全局速率限制以及对无限消息循环导致的拒绝服务攻击的防御不足。查看我们的威胁模型报告以了解这些发现及更多。
我们从安全代码审查中的发现包括代理中一个可远程触发的缓冲区过度读取,会导致堆内存转储到磁盘;多个文件处理问题,可能允许未经授权的用户访问密码哈希;以及对HTTP头的解析不当,可能使攻击者绕过审计能力和基于IP的访问控制用于Mosquitto WebSocket传输。在我们的安全代码审查报告中阅读更多关于这些发现的信息。
Eclipse Jetty
Jetty是最古老和最流行的Java Web服务器框架之一。它与许多其他开源应用程序集成,包括Apache Spark、Apache Maven和Hadoop,以及专有软件如Google App Engine和VMWare的Spring Boot。我们在2023年3月被聘请执行轻量级威胁模型、安全代码审查和修复审查。
由于Jetty代码库的规模以及我们在此次项目中用于威胁建模的时间有限,在确定了要评估的安全控制后,我们进行了轻量级威胁建模练习,专注于识别特定潜在威胁和不安全架构模式跨组件,而不是浅尝辄止地涉及许多潜在漏洞类型。我们与Jetty团队讨论的值得注意的威胁场景包括不安全默认值的影响;例如,我们发现Jetty缺乏默认连接加密,这可能允许对Jetty客户端连接进行中间人攻击,并且头解析不一致,可能允许请求走私或导致其他问题,例如在HTTP/2到HTTP/1降级期间。
以我们在威胁建模练习中探索的场景为导向,我们对Jetty进行了为期三周的代码审查。我们发现了25个发现,包括解析HTTP/2 HPACK头时可能的整数溢出(CVE-2023-36478)导致资源耗尽、由于错误的命令行参数转义导致的命令注入漏洞(CVE-2023-36479),以及Maven元数据文件解析器中的XML外部实体(XXE)注入漏洞。我们的完整报告包括我们的威胁模型、代码库成熟度评估、完整发现列表和修复审查。
Eclipse JKube
JKube是一组有用的插件和库,用于使用Kubernetes或Red Hat OpenShift构建、编辑和部署Docker和OCI容器,直接与Maven和Gradle集成。JKube还可以连接到外部Kubernetes或OpenShift集群以监视、调试和记录事件。在2023年3月至5月与JKube维护者合作期间,我们进行了轻量级威胁模型、安全代码审查和修复审查,评估了在我们安全代码审查后对JKube所做的更改。
在了解了JKube的许多组件、依赖项和集成之后,我们与JKube维护者讨论了几个潜在威胁场景。我们的威胁建模练习识别了缺乏常见安全默认值和许多不安全默认设置,以及多种输入格式类型的手动清理不足和不安全Java反序列化实践的一般模式。我们的安全代码审查测试并扩展了我们在JKube生成工件中不安全默认值的发现。我们的修复审查验证了JKube维护者的代码更改充分缓解了我们的代码审查发现。查看我们的完整报告。
Flux
作为CNCF毕业项目,Flux是一个GitOps和持续交付工具,保持Kubernetes状态与存储在源(如Git仓库)中的配置同步。OSTIF在2023年7月至8月委托Trail of Bits对Flux进行安全代码审查。
我们的审查导致了10个发现,包括一个路径遍历漏洞,攻击者可以利用该漏洞写入指定根目录之外的文件,特别是当Flux作为库包含在其他应用程序中时。我们注意到的其他问题包括未能为缓存的敏感数据设置过期日期,以及Flux macOS二进制文件中的动态库注入漏洞,源于未启用Apple的强化运行时功能。
我们的最终报告包括我们所有发现的细节、代码库成熟度评估、几个可能导致较弱安全态势但被认为没有立即安全影响的代码质量问题,以及关于将我们在评估期间使用的静态分析工具的定期分析纳入Flux的CI/CD管道的建议。
Dragonfly
Dragonfly是一个点对点文件分发和图像加速系统。作为CNCF托管项目,Dragonfly具有下载文件完整性检查、下载速度限制、隔离异常对等点的能力,以及一个旨在成为“Kubernetes的可信云原生仓库”的工件公共注册表。Dragonfly的一个子项目Nydus实现了一个内容可寻址文件系统,以实现云原生资源的高效分发。
2023年7月,Trail of Bits审查了Dragonfly代码库。我们的安全代码审查导致了19个发现,包括五个高严重性问题。我们的发现包括多个服务器端请求伪造(SSRF)漏洞,可能使未经授权的攻击者访问内部服务;点对点API中的一个问题,可能允许攻击者读取和写入对等点机器上的任何文件;以及一个对等点通过为任何IP地址获取有效TLS证书使mTLS认证方案无效的能力。
连同我们发现的细节,我们的最终报告包括代码库成熟度评估、代码质量问题列表、关于在Dragonfly代码库上运行静态和动态分析工具的指导,以及我们的修复审查。
未来展望
这些项目可能已经完成,但我们将继续展示我们对保护互联网开源基础设施的奉献精神。我们也在不断学习!我们在每次评估中迭代和改进我们的方法、静态分析规则集和工具,融入新技术和自动化测试策略,以及客户反馈。期待在2024年初有更多关于我们与OSTIF合作的进行中和未来工作的内容,包括讨论另外两个目前正在进行的安全代码审查。我们还计划发布关于我们对curl模糊测试基础设施改进的深入探讨,以及我们在OSTIF组织的OpenSSL和Mosquitto项目中发现的一些更有趣漏洞的技术细节。
同时,Trail of Bits将继续通过为我们完成的安全代码审查和威胁模型进行修复审查(在合同规定的情况下)来支持OSTIF的使命,以确保我们识别的漏洞和设计缺陷得到缓解。我们非常兴奋地承担OSTIF给我们的进一步工作,无论是威胁建模、安全代码审查还是以其他方式提供安全指导。
如果您喜欢这篇文章,请分享: Twitter LinkedIn GitHub Mastodon Hacker News