3. 回滚与降级攻击剖析
回滚与降级攻击（Rollback & Downgrade Attack）是可信固件体系中最具现实威胁的一类攻击。它并不需要攻破密码算法本身，而是利用固件更新机制中“版本可被替换、旧镜像仍可被接受”的信任缺口，把设备从已修复的高版本强行拉回到存在已知漏洞的低版本，从而重新打开已被封堵的攻击面。理解这类攻击，必须从攻击动机、攻击向量、真实案例与影响四个维度同时切入。
一、核心原理：为什么“旧固件”是攻击者的武器
固件更新链的信任通常建立在签名验证之上：厂商用私钥签名新固件，设备用内置公钥验证签名。但签名只证明“这个镜像来自厂商”，并不天然证明“这个镜像比当前版本更新”。如果设备只校验签名、不校验版本单调性，那么任何一份历史上被合法签名的旧固件，都可以被重新刷入并通过验证。这就是回滚攻击的根因。
降级攻击是回滚攻击的一个变体：攻击者不一定使用完整旧镜像，而是利用更新协议中的版本协商、分块校验或恢复模式，让设备接受一个版本号更低、但签名合法的组件。二者的共同本质是版本单调性（Monotonicity）缺失。防御的核心手段是引入防回滚计数器（Rollback Counter / SVN，Security Version Number），并把它与一次性可编程存储（OTP/eFuse）或可信执行环境绑定，使设备“记得”自己曾经到达过的最高安全版本。
二、攻击动机与攻击向量
攻击者的动机通常分为四类：一是重新启用旧版本中已修复的远程代码执行漏洞；二是绕过新版本引入的权限限制或安全启动策略；三是利用旧固件中已知的调试接口、默认口令或未加密通信；四是在供应链场景中把设备“锁死”在可控版本，便于后续持久化控制。
常见攻击向量包括：
- 更新服务器劫持或镜像替换：攻击者获取到历史签名镜像后，通过中间人、镜像仓库污染或本地升级接口重新下发。
- 恢复模式滥用：许多设备在恢复模式下放宽校验，允许刷入“出厂固件”，攻击者借此注入旧版本。
- 组件级降级：只替换引导链中的某一级（如只降级 BL2 或只降级某个协处理器固件），绕过整体版本检查。
- 版本号伪造：若版本号存放在可写分区且未纳入签名保护，攻击者可直接篡改版本字段，使旧镜像“看起来”更新。
- 回滚计数器回退：若计数器存储在可擦写区域且缺少完整性保护，攻击者可将其清零，使设备重新接受旧版本。
三、历史案例：BootHole 与 Ripple20
BootHole（2020）是回滚与降级攻击的经典案例。该漏洞影响使用 GRUB2 引导程序的 Linux 系统，攻击者可以绕过 UEFI 安全启动（Secure Boot）的验证，加载未签名的内核或引导程序。其关键点在于 GRUB 配置文件（grub.cfg）的解析过程存在缓冲区溢出，攻击者可在受信任的引导阶段执行任意代码。更严重的是，即使厂商发布了修补后的 GRUB，攻击者仍可通过降级到旧版 GRUB 或替换配置文件，重新触发漏洞。BootHole 揭示了引导链中“配置文件与引导程序版本未同步纳入信任度量”的普遍问题。
Ripple20（2020）则从另一个角度说明了降级风险。该漏洞集合影响 Treck 公司 TCP/IP 协议栈，涉及数十个 CVE，波及大量嵌入式与 IoT 设备。由于这些设备往往长期不更新，或更新机制只做签名校验而不做版本强制，攻击者可以利用旧版本协议栈中的漏洞进行远程代码执行。Ripple20 的影响面之所以巨大，正是因为大量设备被“冻结”在存在漏洞的旧固件上，而缺乏有效的防回滚更新通道。
| 案例 | 攻击面 | 降级/回滚关键点 | 影响 |
|---|---|---|---|
| BootHole | UEFI Secure Boot + GRUB2 | 旧版 GRUB 或 grub.cfg 可绕过验证 | 引导链信任被打破，可加载未签名内核 |
| Ripple20 | Treck TCP/IP 协议栈 | 旧固件长期不更新，缺少版本强制 | 大量 IoT/嵌入式设备可被远程控制 |
四、影响分析与防御要点
回滚与降级攻击的影响具有连锁性。第一层是安全边界失效：设备重新暴露于已修复漏洞，攻击者可获得代码执行、权限提升或持久化能力。第二层是信任链断裂：一旦引导链某一级被降级，后续所有度量结果都不可信，远程证明与可信启动形同虚设。第三层是合规与召回成本：设备被降级后可能违反行业安全基线，厂商需要大规模召回或远程强制升级。
防御上应遵循以下要点：
- 在引导链每一级引入安全版本号（SVN），并写入 OTP/eFuse，确保版本只能递增。
- 将版本号、回滚计数器纳入签名保护范围，防止被单独篡改。
- 恢复模式必须执行与正常升级相同的签名与版本校验，禁止“出厂固件”绕过。
- 对组件级更新实施独立版本控制，避免只降级某一级而绕过整体检查。
- 建立更新日志与远程证明机制，及时发现异常降级行为。
# 典型的防回滚校验伪代码
verify_update(image):
if not verify_signature(image, pubkey):
return REJECT
if image.svn < device.current_svn:
return REJECT_ROLLBACK
if image.version <= device.current_version:
return REJECT_DOWNGRADE
return ACCEPT
复盘来看，BootHole 与 Ripple20 的共同教训是：固件安全不能只依赖“签名”这一层，而必须把版本单调性、计数器完整性和恢复模式策略一起纳入信任模型。只有让设备“记住”自己曾经到达的安全高度，才能真正封堵回滚与降级攻击的入口。