开源Zephyr和MCUboot堆栈中的26个缺陷

开源 Zephyr RTOS 和 MCUboot 项目在物联网生态系统中的供应商和开发人员中越来越受欢迎，因为它们一起包括开发适合的成熟应用程序所需的所有驱动程序、库、堆栈和文件系统微型边缘设备。他们是免费的也没有什么坏处。

与任何开源技术一样，维护和改进 Zephyr 和 MCUboot 代码库属于社区，这在许多人看来等同于提高安全性。事实上，福布斯最近一篇报道 Zephyr 项目的文章指出“开源软件通常被认为更安全，因为任何人都可以检查和调试代码。 ”

全球最大的安全咨询公司之一NCC 集团最近进行了一项独立研究检查，分析了 Zephyr RTOS 和 MCUboot 安全引导加载程序的安全状况，发现了更多 26 个不同严重程度的漏洞。

NCC 研究主管 Jennifer Fernick 与 Embedded Computing Design 就该公司“研究报告 - Zephyr 和 MCUboot 安全评估”中的发现进行了交谈。

在您对 Zephyr RTOS 和 MCUboot 安全引导加载程序的检查中发现了哪些严重漏洞，更重要的是，它们对物联网系统的安全性有何影响？

FERNICK：本报告中的研究重点是 Zephyr RTOS 和 MCUboot 引导加载程序，研究人员在其中发现了 Zephyr 中的 25 个漏洞和 MCUboot 中的 1 个漏洞。我们知道 Zephyr RTOS 拥有约 3% 的物联网市场份额，并且由于包括英特尔、NXP、Nordic Semiconductor 等许多芯片组制造商的支持，这种影响力正在迅速增长。

关键漏洞都在 Zephyr 网络堆栈中，其中包括堆栈缓冲区溢出攻击和内存损坏漏洞。通过利用这个特定的缓冲区溢出，当在启用特定构建选项的设备上接收到恶意 ICMP 数据包时，攻击者可能会导致拒绝服务或在设备内核中执行代码，而通过利用这个特定的内存损坏漏洞远程攻击者可以发送带有格式错误的标头的 MQTT 数据包，以在 Zephyr 内核中引发内存损坏，从而可能导致代码执行。

高风险漏洞既是 Zephyr USB 堆栈中的数据验证错误，也包括用于通过 USB 进行固件更新的驱动程序中的全局缓冲区溢出攻击，以及 USB 大容量存储驱动程序中的任意读取/限制写入。通过利用这些 USB 漏洞，对 Zephyr 设备具有物理访问权限的攻击者可以诱导拒绝服务或可能在内核中实现代码执行。拒绝服务漏洞可能意味着部署在远程位置的物联网设备可能需要物理访问设备以执行手动重启，然后设备才能再次运行，并且内核级代码执行允许攻击者破坏并完全控制设备，运行任意代码，破坏设备的功能，

修复这些 Zephyr 漏洞有多难？让我们特别关注 USB 堆栈中的那些？

FERNICK： NCC Group 报告了 Zephyr USB 堆栈中的五个漏洞。风险最高的漏洞是USB DFU 模式可以溢出 DFU_Upload 命令中的全局缓冲区以及 USB 海量存储驱动程序中的任意读取和有限写入。

USB DFU 模式全局缓冲区溢出攻击涉及利用 Zephyr 的 USB DFU 驱动程序中存在的缓冲区溢出漏洞，该驱动程序通常用于通过 USB 进行本地固件更新。通过此漏洞，对设备具有物理访问权限的攻击者至少能够在设备内引发拒绝服务，在某些情况下甚至可以在内核中执行代码，方法是通过以下方式将恶意负载插入内部闪存USB DFU 接口，然后触发全局缓冲区溢出。但是，应该注意的是，这种可利用性取决于特定 Zephyr 构建的内存布局。此问题已得到修复，可以通过对特定输入变量的大小进行基本检查以减轻缓冲区溢出来解决。

在研究 USB 海量存储驱动程序时，我们的团队发现 USB 海量存储驱动程序（用于使 Zephyr 设备充当 USB 存储驱动器）与 RAM 存储之间的交互存在问题大于 RAM 磁盘总大小的地址将导致 USB 驱动程序出错，从而导致恶意磁盘读取查询能够读取超过全局缓冲区末尾的内存，这可能会泄露内核内存内容并启用攻击者在内核中获取代码执行。此问题已得到修复，可以通过对特定输入变量中的大小进行基本检查来缓解缓冲区溢出，并确保以不会无意中从生产构建中剥离的方式执行边界检查。

一个中等风险的漏洞是USB 大容量存储器内存写入处理程序中大小未对齐的越界写入。memoryWrite 处理程序中的发现是，当 USB 数据包和存储块大小未对齐时，在从 buf 到页面的 USB 传输数据的复制过程中，页面数组可能会被覆盖，这取决于特定全局变量的布局/顺序，可能在有些情况是可以利用的。此问题已得到解决，可以通过增加页面缓冲区的大小以满足某个最小阈值以及在写入完成后将任何剩余数据移动到缓冲区的开头来解决此问题。

另一个中等风险漏洞是USB 海量存储驱动程序写入和验证处理程序中的整数下溢。此漏洞与 Zephyr 中的 memoryWrite 和 memoryVerify 函数有关，其中输入清理未正确执行，导致整数溢出。此漏洞使攻击者能够根据所选大小值泄漏堆栈内存内容或破坏全局内核内存，但仅可用于特定内存布局，因为攻击者不直接控制堆栈缓冲区的必要部分。此问题已以类似于前面讨论的其他输入清理检查的方式修复。

最后，一个低风险漏洞是USB DFU 模式允许读取主插槽绕过图像加密。这一发现意味着，在启用（可选）USB DFU 模式时，可以通过在启用 Zephyr USB DFU 和 MCUboot 加密映像功能时使用上传命令从主映像插槽中读取明文固件映像来解密加密固件映像。 这种攻击需要对设备进行物理访问。此问题尚未得到解决，但可以通过在 Zephyr 中提供禁用 DFU_Upload 命令的选项（允许读取固件映像）或简单地在 MCUboot 文档中说明绕过固件映像加密是“允许以任何方式转储内部闪存的攻击向量，”文档警告说，MCUboot 的威胁模型并未涵盖这一点。

MCUboot 应该能够覆盖多少 Zephyr 中的潜在危害，以及在开源安全引导加载程序中发现的漏洞的影响是什么？

FERNICK：引导链实现的稳健性在嵌入式操作系统的安全性中起着重要作用。在 Zephyr 和 MCUboot 的情况下，MCUboot 执行大部分启动时固件完整性验证检查，尽管 Zephyr 对运行时执行的固件升级保留一些责任。此外，安全启动保证所需的芯片配置的某些方面超出了 两者的范围 MCUboot 和 Zephyr，而是在制造过程中由设备 OEM 负责。这方面的一些示例包括禁用 JTAG 或 SWD 以防止运行时调试，或启用闪存读取保护以防止提取设备机密。因此，安全引导链对于运行 Zephyr 或任何其他 RTOS 的嵌入式系统的高度安全保证是必要的，但还不够。出于这个原因，来自整个供应链的多个级别的利益相关者和组件必须承担特定的责任，以确保实现所需的安全属性。

MCUboot漏洞是串行启动过程中对未初始化变量的潜在访问，意味着由于MCUboot中的输入处理函数存在缺陷，该函数可能会利用未首先初始化的变量，如果该值这个变量非常大或非常小，它可能会写入内存或整数下溢/溢出，最终在解码字节写入输出缓冲区时导致内存损坏。

那么这对 Zephyr/MCUboot 用户意味着什么呢？应该避免它们吗？有快速修复吗？还有什么？

FERNICK：经过初步安全审查后，与内部未经审查的同类系统相比，用户对 Zephyr 和 MCUboot 的安全性有了一定程度的信心。但是，我要提醒的是，审查所需的覆盖范围优先考虑了一些被认为具有最高安全风险的系统组件，而其他系统组件则未经检查，因此并不完整。全面的安全审计需要进一步的工作。

研究人员确实发现了一些进一步的内核加固机会，以及许多不正确的系统调用验证的证据，即内核/用户隔离在系统范围内不一定是健壮的。

不正确的数据验证是不安全代码中的常见漏洞类型，无论生态系统如何 - 例如，未能验证用户生成的输入数据是 SQL 注入攻击和跨站点脚本的根本原因，这些攻击无处不在，足以成为其中的一部分OWASP 前十名。当然，物联网设备作为一个类别往往以经常包含更多漏洞而闻名，这些漏洞通常会在其他类型的系统中看到，包括但当然不限于数据验证漏洞。

一般来说，当嵌入式设备和用于构建物联网设备的相关组件的设计者和制造商认真对待安全性时，物联网设备的用户会更加安全，例如拥有漏洞披露程序、默认启用产品安全性等。设计和运营承诺，例如最近在 ioXt 承诺中概述的承诺。

Zephyr 项目对所披露的漏洞的反应非常好，其中最高风险的组件和其他几个已被修补，并且 Zephyr 项目似乎热衷于向他们的用户宣传我们的发现和项目的总体安全性。在我们向 Zephyr 团队披露我们的发现后，他们创建了一个 产品创建者漏洞警报注册表， 以帮助他们更好地与在其产品中使用 Zephyr 的客户建立联系。致力于不断提高安全性以及围绕减轻物联网设备中的安全风险进行透明通信是朝着更安全的世界迈出的重要一步。

审核编辑：郭婷