开发者改进Xbox 360 Hypervisor漏洞利用，执行时间缩短至数秒

Rock Band Blitz 正在运行 Bad Update 漏洞利用文件。 Hypervisor 竞态条件优化 在发现 RBB 入口点后不久，我收到了来自“Máté”的 pull request，他对漏洞利用中 hypervisor 竞态条件部分做了一些改进。这些改进包括：用哈希表预计算并存储恶意密文值、更好的缓存刷新原语，以及改进 XKE payload 线程与密文覆写线程之间的线程调度。这些改进结合起来，将执行时间缩短到几秒钟，并且竞态条件的成功率也大大提高。 在第 2 部分中，我谈到了如何通过使用 hypervisor API 在预定内存地址创建加密内存分配，并利用两条不同的内存路径来捕获某些选定明文数据对应的密文，从而攻击加密内存。利用这个原语，我能够构造密文数据以实现内核模式代码执行，同时也构造出用于攻击 bootloader 更新 XKE payload 中 LZX 解压缩代码的密文数据。 内存加密方案中使用的白化值（whitening value）为 12 位，这意味着对于给定的明文数据，共有 1024 种唯一的密文组合。然而，在我最初的 PoC 中，我只为 1024 个可能白化值中的一个生成了密文，原因是我这边存在两个问题。最初对密文攻击进行原型设计时，我确实尝试过使用查找表来处理密文组合，但没能让它正常工作。 第一个问题是我使用的是一个非常古老的、大约 2011 年时期的 hypervisor/内核构建（我所有早期研究都基于它），该版本在设置内存加密的 hypervisor 函数中会对加密虚拟地址范围执行 TLB 刷新。在后来的 hypervisor 构建中，这个 TLB 刷新被移除了，因为该 hypervisor 函数的内核包装函数已经对虚拟地址范围执行了 TLB 刷新。然而，我直接调用 hypervisor 系统调用（跳过了执行 TLB 刷新的内核包装代码），而且由于 TLB 是惰性加载的，白化位会变得陈旧，导致从内存中读出的密文无效。 旧版 hypervisor（左）与新版 hypervisor（右）对比，后者缺少 TLB 刷新 在 17559（最新）版本的 hypervisor 上测试漏洞利用时，查找表导致了问题，而我没有去调查，而是决定以后再修，然后继续推进。等到我完成漏洞利用的末尾部分时，我已经因为追逐 CPU 缓存问题而陷入了严重的隧道视野，以至于说服自己查找表根本行不通。我可能应该做的（除了在查找表问题出现时就去调查之外）是把项目搁置几周，以清晰的心态再回来。算了，吃一堑长一智…… 深入哈希表的实现细节：我们使用期望在内存中看到的密文的前 N 位作为索引，指向两个数组。第一个数组包含 oracle 密文的前 64 位，用于在哈希表发生冲突时进行验证。第二个数组存储我们想要写入内存的恶意密文。