虹科在RAUC嵌入式固件更新框架中发现重大漏洞

● 虹科Vdoo安全研究团队不断研究领先的嵌入式设备及其供应链，在RAUC 嵌入式固件更新框架中发现的重大漏洞——

● CVE-2020-25860是一个潜在的严重漏洞，其在RAUC中的 CVSSv3 得分为 8.8。此漏洞存在于 RAUC 的所有版本中，直到 1.5，其中包含补丁。

该漏洞是一个 Time-of-Check-Time-of-Use （ CWE-367 ） 问题允许有权限的攻击者在固件更新文件被验证后（但在安装完成前）覆盖它，从而允许安装一个任意的固件更新，绕过加密签名检查机制。

● 与供应链漏洞一样，很难准确估计有多少设备受其影响。鉴于RAUC这是一个开源工具，而且许多与供应商没有关系的不同公司都可以使用它，因此这种估计更加复杂。

RAUC背景

RAUC—Robust Auto-Update Controller，该项目始于 2015 年，被开发为轻量级工具，可为基于 Linux 的嵌入式设备执行故障安全的图像更新。 RAUC 允许嵌入式 Linux 开发人员在他们的嵌入式设备上集成一个强大的更新客户端，只需最少的努力，同时避免编写任何更新代码。RAUC框架支持许多常见的引导程序（U-Boot、grub等）和存储技术（ext4、UBIFS等），因此，它试图尽可能地接近嵌入式设备固件更新的 “统包”解决方案。 RAUC 的主要特性是安全性（原子性、故障安全更新操作）、保障性（加密签名检查）和可定制性（在安装过程中添加用户挂钩）。

技术深究

RAUC 使用捆绑文件作为保存新固件的存档。我们发现在固件升级过程中，此文件可以被攻击者替换（在初始验证步骤之后），并且通过这样做会安装恶意固件，从而有效地允许攻击者控制系统。运行rauc install bundle.raucb时RAUC 会运行以下内部函数：

check_bundle（） – 使用 openssl 库调用验证包

mount_bundle（） – 使用“mount”shell 调用挂载包

在这些步骤之后，安装的包被提取并覆盖当前固件。关键问题在于一旦 check_bundle（） 完成运行，捆绑文件就会关闭，并且不会以任何方式保留已验证的数据。当 mount_bundle（）开始运行时，mountshell 调用会导致重新读取包数据：

gboolean mount_bundle（RaucBundle *bundle， GError **error）{...g_message（“Mounting bundle ‘%s’ to ‘%s’”， bundle-》path， mount_point）;

res = r_mount_loop（bundle-》path， mount_point， bundle-》size，...gboolean r_mount_full（const gchar *source， const gchar *mountpoint， const gchar* t

gboolean r_mount_full（const gchar *source， const gchar *mountpoint， const gchar* type， goffset size， const gchar* extra_options， GError **error）{...if （getuid（） ！= 0） { g_ptr_array_add（args， g_strdup（“sudo”））;

g_ptr_array_add（args， g_strdup（“--non-interactive”））; } g_ptr_array_add（args， g_strdup（“mount”））;...g_ptr_array_add（args， g_strdup（source））;...sproc = r_subprocess_newv（args， G_SUBPROCESS_FLAGS_NONE， &ierror）;...

因此——攻击者可以在调用 check_bundle（） 和mount_bundle（） 之间切换包文件。这让攻击者可以部署任意恶意固件，基本上可以在设备上提供root权限。

图 ：攻击流程，当进程到达 mount_bundle（） 时，攻击者可以替换包文件，因此 RAUC 将挂载未经授权的包

赢得竞争条件（在检查/挂载包调用之间替换包文件）的机会非常高，因为在包括shell 调用（“mount”命令）在内的两个操作之间存在不可忽略的代码量，这是一个非常缓慢的操作。

观察到的远程攻击场景

尽管在大多数情况下，虹科认为该漏洞可作为本地权限升级加以利用，但我们观察到一个真实场景，即远程攻击者可利用一组默认硬编码凭据利用该漏洞。目标设备使用了一组默认的硬编码凭据（用户名和密码设置为“admin”），首次登录时不需要更改这些凭据。这些凭证可以被能够访问设备固件的攻击者轻易提取，或者通过简单的暴力攻击来猜测。

查看设备的攻击面：

目标设备暴露了一个经过认证的 CGI 端点upload.cgi，它允许将任意文件上传到硬编码的文件路径 -/tmp/rauc/bundle.raucb

目标设备暴露了一个经过认证的 CGI 端点install.cgi，该端点运行硬编码的 shell 命令 -rauc install /tmp/rauc/bundle.raucb

两个 CGI 端点之间没有适当的锁定机制

在这种情况下，攻击者可以远程接管设备，只需调用：

upload.cgi 带有正确签名的固件

install.cgi

（很快）upload.cgi带有恶意固件

本地攻击场景和PoC

假设本地用户有调用 RAUC 的权限（例如，通过只允许rauc命令的 sudo 配置），但没有签署RAUC捆绑包所需的私钥，利用是没有价值的：将正确签名的固件复制到某个路径，例如： 。/bundle.raucb Invoke RAUC –sudo rauc install./bundle.raucb迅速用恶意的固件替换。/bundle.raucb

如果本地用户无法调用 RAUC 命令，假设调用 RAUC 命令的特权用户使用攻击者可以写入的路径，则这种情况也可以被利用。我们开发了一个概念验证，它利用了这个确切的场景：

PoC 接受要替换的包文件的完整路径

PoC通过监控一个默认目录（/mnt/rauc）来等待另一个用户运行rauc安装，该目录在验证步骤之后但在安装步骤之前被创建。

一旦验证结束（目录被创建），PoC 就会用任意的输入覆盖包文件。

攻击的bundle文件可以被移到正确签名的bundle文件上（这比在正确的位置写一个新文件要快）。

作为设备供应商

如何知道设备是否受此漏洞的影响？

可以通过在您的设备上运行此命令来检查您的RAUC 版本是否存在漏洞：

rauc --version

如果报告的版本低于1.5，则您的设备包含有漏洞的代码。实际上，只有当本地或远程攻击者有可能在安装捆绑包时修改该文件，该设备才会有漏洞。例如，这可能发生在以下情况：

非特权用户可以通过sudo机制、setuid机制或任何其他专有机制，以root权限调用rauc命令。例如，/etc/sudoers文件中的以下行将允许“vdoo”用户以 root 身份调用RAUC：

vdoo ALL=（root） /usr/bin/rauc

rauc install可以由非特权用户修改的捆绑路径随时调用。例如：

/usr/bin/rauc install /tmp/mybundle.raucb

由于/tmp默认情况下是全局可写的，因此通常任何用户都可以修改其下的文件。

虹科Vdoo 在其Vision平台中添加了一个适用性扫描器，可以通过检测所有RAUC 调用并检查相关安装路径的权限来自动验证是否发生这种情况，为您的设备保驾护航。

作为资产所有者

如何知道部署的设备是否存在漏洞？

不幸的是，似乎很难判断此漏洞是否存在，更重要的是，仅仅使用网络工具或不实际查看设备代码，就很难适用。

如果您的设备供应商为设备提供了软件物料清单 （SBOM），请查看是否使用了 RAUC，如果使用了，那么理论上您很可能容易受到攻击（除非版本明确列为 1.5），因为有漏洞代码存在。但这并不意味着该漏洞是可利用的。如有需要，请随时联系虹科Vdoo为您提供帮助。

如果无法升级RAUC

如何降低风险？

如上所述，这是一个经典的Time-of-Check-Time-of-Use 漏洞，其中攻击利用非原子性的动作，涉及到对资源的检查和资源的使用。在这种情况下，进行签名检查，用法为安装/升级。

通过确保安装是原子性的并且从安全路径发生，可以减轻攻击。在运行rauc install之前，将捆绑文件从全局可写位置复制到安全位置（仅限 root 可写）并从该路径运行安装。使用安全位置的存在作为锁定机制。这将确保未经授权的用户（无论是本地还是远程）无法插手安装过程。

这可以通过这个示例 shell 脚本来完成：

# Assuming firmware is uploaded to /tmp/uploads/bundle.bin# Assuming /data/fw_upgrade can be written to only by rootif ［ ！ -e /data/fw_upgrade/bundle.bin ］;

then cp /tmp/uploads/bundle.bin /data/fw_upgrade/bundle.bin /usr/bin/rauc install /data/fw_upgrade/bundle.bin rm /data/fw_upgrade/bundle.binfi

请注意，在使用像Yocto这样的构建系统时，更改安装脚本可能并不比切换到固定的RAUC版本容易得多。

﹀

﹀

﹀

附录-虹科Vdoo安全性防护平台

虹科Vdoo是端到端的产品安全分析平台，在整个产品生命周期中自动化所以软件安全任务，确保所有安全问题得到优先处理、沟通和缓解。垂直无关的平台使各种行业的设备制造商和部署者能够跨多个业务线扩展其产品安全功能。虹科Vdoo自动保护连接产品的方法使客户大大缩短了上市时间，减少了资源需求，增加了销售量，降低了总体风险。

责任编辑：haq