ARM PAC指针认证的侧信道攻击——PACMAN安全漏洞

[Q1. PACMAN论文的内容是什么？](#Q1. PACMAN论文的内容是什么？)

[Q2. Arm处理器是否存在漏洞？](#Q2. Arm处理器是否存在漏洞？)

[Q3. 受Arm合作伙伴架构许可设计的处理器实现是否受到影响？](#Q3. 受Arm合作伙伴架构许可设计的处理器实现是否受到影响？)

[Q4. Cortex-M85受到影响吗？](#Q4. Cortex-M85受到影响吗？)

[Q5. Cortex-R82受到影响吗？](#Q5. Cortex-R82受到影响吗？)

[Q6. 指针认证如何保护软件？](#Q6. 指针认证如何保护软件？)

[Q7. PACMAN的详细工作原理是什么？](#Q7. PACMAN的详细工作原理是什么？)

[Q8. PACMAN的局限性是什么？](#Q8. PACMAN的局限性是什么？)

[Q9. 用户是否应对PACMAN感到担忧？](#Q9. 用户是否应对PACMAN感到担忧？)

[Q10. 是否有可用于缓解PACMAN的方法？](#Q10. 是否有可用于缓解PACMAN的方法？)

Arm最近得知PACMAN漏洞的存在（详见https://pacmanattack.com/），本文解答了有关该漏洞的问题。本文涉及以下10个问题：

PACMAN论文的主题是什么？
Arm的CPU是否受到影响？
由Arm的合作伙伴根据架构许可设计的处理器实现是否会受到影响？
Cortex-M85是否受到影响？
Cortex-R82是否受到影响？
指针认证如何保护软件？
PACMAN的详细工作原理是什么？
PACMAN有哪些局限性？
用户是否应对PACMAN感到担忧？
是否有可用于缓解PACMAN的方法？

如果您是Arm被许可方，并有其他问题，请联系您的客户团队以获取更多信息。

Q1. PACMAN论文的内容是什么？

麻省理工学院的研究人员发表了一篇描述PACMAN技术的论文。该方法利用恶意软件对指针认证代码（PAC）进行暴力破解。这种技术使用speculation（推测、投机）来创建一个"oracle"以确定这些代码。这允许攻击者利用这些代码来降低指针认证提供的保护，以对抗面向返回编程（ROP）和面向跳转编程（JOP）攻击。ROP和JOP将现有例程的片段链接在一起形成gadgets"小工具"，然后可以利用这些小工具构建更大的功能序列，用于进一步的攻击。

有关详细信息，请查阅发布在https://pacmanattack.com/上的论文。

Q2. Arm处理器是否存在漏洞？

是的。一些支持指针认证功能（FEAT_PAuth或FEAT_PAuth2）的Cortex-A、Neoverse处理器和其他Arm处理器实现容易受到PACMAN攻击。

指针认证功能是在Arm架构版本Armv8.3-A中引入的。在Arm架构的后续版本中，指针认证功能已经得到增强，引入了一个故障特性（FEAT_FPAC），允许在指针认证尝试失败时引发故障。这个故障特性在本文末尾的Q10中所解释的缓解措施中是必要的。

【注意】对于Cortex-A和Neoverse CPU, ID_AA64ISAR1_EL1寄存器中的API位表示该CPU上是否可用指针身份验证或故障特性(FEAT_FPAC) 。相关寄存器功能查询请参考http://hehezhou.cn/

下表提供了支持指针认证的已发布处理器是否受到影响的信息："漏洞状态"为"受影响"表示列出的CPU容易受到PACMAN攻击。

Q3. 受Arm合作伙伴架构许可设计的处理器实现是否受到影响？

Arm无法对合作伙伴的实现进行评论。请直接联系这些合作伙伴。

Q4. Cortex-M85受到影响吗？

不受影响。Cortex-M85实现了PAC的M-class版本，但并不容易受到攻击。A类和M类PAC架构之间存在区别，避免了这种攻击。M类认证指令在对错误的PAC进行认证时会生成同步故障，而不是修改寄存器结果（这可能允许通过其他侧信道推测性地检测和泄漏认证状态）。

还请注意，M类的PAC是一个完整的32位值，因为它保存在一个单独的寄存器中（而不是存储在指针的高16位地址位中）。这意味着在M类CPU上，任何可能的PAC空间都会比A类CPU上的空间大得多。此外，指针本身在M类设备上不会被修改，因此在推测地执行无效的认证步骤时，内存访问模式不会发生变化。

最后，这些类型的攻击通常需要一个开放的软件堆栈或用户可以将恶意代码加载到系统上的其他方法。通常，Cortex-M设备的使用模型是使用闭源软件堆栈。

Q5. Cortex-R82受到影响吗？

Cortex-R82实现了故障特性（FEAT_FPAC），但并不容易受到攻击。当在执行对PAC进行认证的指令时，Cortex-R82在推测性执行时表现与易受攻击的A类CPU不同，该行为不允许攻击软件创建"oracle"。

Q6. 指针认证如何保护软件？

攻击者可以利用内存破坏漏洞来更改存储在内存中的指针或返回地址，然后劫持程序的控制流。遵循这一模式的攻击包括面向返回编程（ROP）和面向跳转编程（JOP），其中攻击者将指向执行所需任务的代码片段（称为"小工具"）的指针链接在一起。

指针认证通过在地址的未使用高位插入指针验证码（PAC），保护内存中的指针免受恶意篡改。这个代码充当签名，它在对指针进行解引用（在间接分支或内存访问时）之前进行验证。如果指针被篡改，认证很可能会失败，CPU将引发故障，从而抵御攻击。

有关更多信息，请参阅《ARM安全架构------为复杂软件提供保护》文档。

Q7. PACMAN的详细工作原理是什么？

PACMAN是一种技术，允许攻击者通过滥用推测执行来暴力破解PAC。需要强调的是，只有在攻击者已经具备破坏内存中受保护指针的能力的情况下，PACMAN才能发挥作用。由于指针认证的存在，为了修改受保护的指针，攻击者需要找到有效的PAC。

在受影响的CPU上，失败的AUT指令会以一种使得解引用导致翻译故障的方式修改指针。执行路径（通过和认证失败的路径）之间的差异可能会转化为不同的微架构副作用，如果被观察到，就会创建一个"推测性oracle"。

微架构副作用的经典例子包括TLB和缓存分配，可以通过时间测量观察到。具体而言，PACMAN论文依赖于TLBs。错误指令永远不会retire，因为错误预测的分支会刷新pipeline，错误不会发生，攻击者可以重复，直到找到有效的PAC。

PACMAN的主要思想是，攻击者可以通过在推测执行下触发AUT指令的执行（例如，通过错误预测的分支，类似于Spectre攻击），调用这个"oracle"并使用不同的PAC值（每次触发内存破坏时）直到找到有效的PAC为止。在这一点上，攻击者将通过创建具有有效PAC的恶意指针来继续攻击。

Q8. PACMAN的局限性是什么？

正如上文所述，PACMAN有几个要求和限制：

能够破坏受害者内存中的指针。
找到一个合适的"小工具"，即能够控制目标AUT指令在推测执行下执行。
支持PAC的易受攻击CPU在推测执行下执行AUT指令时产生不同的微架构副作用。
能够观察到这些通常比较杂乱的微架构副作用（例如，TLB分配）。
PAC keys预计会根据执行上下文的变化而变化；在一个上下文中有效的PAC在不同的上下文中可能会失效。
推测窗口的持续时间设定了可以执行和链式执行的"小工具"数量的上限。此外，每个"小工具"的微架构副作用必须能够被攻击者区分。

需要注意的是，这些要求使得远程攻击变得极不可能，因此攻击者必须能够加载和运行恶意软件或脚本到系统中。然而，在类似JavaScript的JIT环境中，这可能会变得更容易。

Q9. 用户是否应对PACMAN感到担忧？

Arm已经审查了PACMAN论文，虽然它提出了一种新颖且有趣的推测侧信道变体，但Arm认为指针认证仍然在防范ROP和JOP等攻击方面提供了相当大的价值。

用户应该意识到，没有使用指针认证构建的软件已经容易受到ROP/JOP的攻击，因此在该软件上执行这些攻击并不需要PACMAN。

此外，考虑到PACMAN的局限性和推测攻击的历史，我们认为在实际应用中不太可能使用PACMAN来破解指针认证。

Q10. 是否有可用于缓解PACMAN的方法？

对于通用软件，Arm建议继续使用标准的保护机制（在上文Q6中讨论，并在《ARM安全架构------为复杂软件提供保护》文档中有详细介绍），因为它们可以防范ROP和JOP攻击。

可以通过以下代码序列进一步缓解PACMAN。然而，这需要提前了解运行代码序列的CPU的具体实现，并且带有额外的性能影响。

对于实现故障特性（FEAT_FPAC）的CPU，使用XPAC指令（见下图）在每个AUT指令之后显式清除PAC字段将阻止PACMAN攻击创建"oracle"的能力。然而，这意味着不能使用组合认证和分支或认证和加载指令。

【注意】

上图的方法依赖于故障的AUT指令不会stalling younger指令，这在Arm实现中是成立的。一个替代且性能更好的序列，可以避免这种限制，但需要牺牲一个额外的寄存器（在下面的示例中为X3），是将上图中的以下代码序列进行转换：

LDR X0, [X1]
AUT X0
XPAC X0
LDR X2, [X0]

into:

LDR X0, [X1]
MOV X3, X0
XPAC X0
AUT X3
LDR X2, [X0]

【警告】

上述缓解方法不应在未实现故障特性（FEAT_FPAC）的CPU实现上使用，因为这实际上会禁用PAC提供的保护。ID_AA64ISAR1_EL1寄存器中的API位指示在给定的Cortex-A或Neoverse CPU上是否可用指针认证或故障特性（FEAT_FPAC）。

在无法实际使用XPAC指令或CPU未实现故障特性（FEAT_FPAC）的情况下，用户可以在AUT指令之后添加推测barriers。然而，Arm认为在所有可能的情况下使用推测barriers将对性能产生严重的影响。

无论CPU是否支持故障特性（FEAT_FPAC），Arm仍然强烈建议在当前Arm CPU中使用指针认证来缓解ROP/JOP风格的攻击。如果没有指针认证来防范ROP/JOP攻击，攻击者可能会迅速且轻松地创建ROP/JOP小工具。

参考

https://developer.arm.com/documentation/ka005109/latest/

http://hehezhou.cn/

ARM安全架构------为复杂软件提供保护