虹科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* 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权限。
赢得竞争条件（在检查/挂载包调用之间替换包文件）的机会非常高，因为在包括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 root
if [ ! -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.bin
fi
请注意，在使用像Yocto这样的构建系统时，更改安装脚本可能并不比切换到固定的RAUC版本容易得多。