【Hacker News搬运】ZenHammer：基于AMD Zen平台的Rowhammer攻击

[hackernews]

Title: ZenHammer: Rowhammer attacks on AMD Zen-based platforms

ZenHammer：基于AMD Zen平台的Rowhammer攻击

Text:

hn link

Url: https://comsec.ethz.ch/research/dram/zenhammer/

研究人员的工作表明，尽管部署了TRR缓解措施，但仍然可以在AMD Zen 2和Zen 3系统上的DDR4设备上触发Rowhammer位翻转。这一结果证明，AMD系统与Intel系统一样，都容易受到Rowhammer攻击，这大大增加了攻击面，考虑到今天AMD在x86桌面CPU市场上的份额约为36%。这提出了一个重大风险，因为野生的DRAM设备无法轻易修复，而且先前的工作表明，Rowhammer攻击是实用的，例如，在浏览器中、在智能手机上、在虚拟机之间，甚至通过网络。此外，研究人员还展示了ZenHammer可以在DDR5设备上首次触发Rowhammer位翻转。

研究人员的结果显示，Zen 2和Zen 3系统上的位翻转数量很高。此外，Zen 3上的设备比Coffee Lake更容易受到攻击，简化了利用。研究人员可以使用先前工作在7/6/4个这些设备上构建页表、RSA公钥篡改和sudo利用，平均分别需要164/267/209秒。

研究人员通过采用针对AMD系统的DRAMA技术反向工程了秘密的DRAM地址功能。他们发现，必须更改计时程序以获得更可靠的结果。他们做出了一个关键观察，即在系统地址映射（ see Figure 1）之前，必须将物理偏移应用于物理地址以恢复DRAM地址功能。这使得可以完全恢复地址功能。然而，使用这些地址功能在我们的5和0的10个AMD Zen 2和Zen 3设备上只给出了非常少的位翻转，正如我们在表1中所展示的。

研究人员开始研究刷新同步， previous work (e.g., SMASH, Blacksmith) 表明刷新同步对于触发位翻转很重要。他们证明了使用非重复行的连续计时测量在AMD上进行精确和可靠的刷新同步是有效的。列表1显示了他们改进的刷新同步方法。

研究人员发现，非均匀Rowhammer模式在AMD Zen+/3系统上的激活率显著低于Intel Coffee Lake（见图2）。为了调查这一点，他们进行了一系列实验，寻找最佳的敲击指令序列。结果显示，使用常规加载（MOV）与CLFLUSHOPT刷新攻击者，立即在访问攻击者后发出（“分散”风格）是最佳的。它还揭示了，与Zen 2不同，在刷新后不需要显式围栏。

研究人员进一步调查了不同的围栏类型和围栏调度策略如何影响AMD Zen系统上的Rowhammer模式。为此，他们提出了六种模式感知和缓存避免的围栏调度策略（见表2），并在我们的设备上测试了它们，每种策略测试6小时，以确定设备的最佳策略。他们发现，在大多数Zen 2设备上，最佳策略是SP_none，而在Zen 3上，SP_pair通常更适合。

研究人员对抓取的内容进行了分析，评估了这些位翻转的利用性，基于之前工作中的三种攻击：（i）针对页表项的页帧号进行攻击，以使其 pivot 到攻击者控制的页表页；（ii）针对用于SSH主机认证的RSA-2048公钥的攻击，允许恢复与之关联的私钥；（iii）针对sudoers.so库的密码验证逻辑的攻击， enable gaining root privileges. 他们报告了表4中的结果。

研究人员还尝试在DDR5上使用ZenHammer，通过采用AMD Zen 4上的DRAM功能反向工程，并对十种DDR5设备进行评估。在这十种设备中，ZenHammer能够在一种设备上触发约42k位翻转。这是首次公开报告的在高通系统上的DDR5位翻转。然而，由于ZenHammer无法在九种中的十种设备上触发位翻转，我们得出结论，需要进行更多研究以找到DDR5设备的更有效的模式。

研究人员的工作得到了瑞士国家科学基金会的支持（SNSF），资助号51NF40_180545，瑞士联邦教育、研究和创新司（SERI）的资助，合同号MB22.00057（ERC-StG PROMISE），以及微软瑞士JRC资助。

Post by: transpute

Comments:

tdullien: Coauthor of the original Rowhammer exploit here. ECC remains a highly effective method for turning this from a security issue to a reliability issue, <i>mostly</i>. As an individual owner of a server, if that server has ECC and you expect to notice machine halts due to uncorrectable ECC errors, the security implications for you are modest.<p>Now, if you are a cloud provider that provides VMs on multitenant hosts, your threat model may be different.<p>Either way, avoid machines without ECC. TRR was a lame duck even when Rowhammer was still fresh, and bits flipping in DRAM will not go away unless the economics in DRAM manufacturing change (e.g. not).

tdullien: 这里是原始Rowhammer漏洞的合著者。ECC仍然是一种非常有效的方法，可以将其从安全问题转变为可靠性问题，<i>主要是</i>。作为服务器的个人所有者，如果该服务器有ECC，并且您希望注意到机器由于无法纠正的ECC错误而停止，则对您的安全影响是适度的<p> 现在，如果您是在多租户主机上提供虚拟机的云提供商，那么您的威胁模型可能会有所不同<p> 无论哪种方式，都应避免使用没有ECC的机器。即使在Rowhammer还很新鲜的时候，TRR也是一只跛脚鸭，除非DRAM制造业的经济状况发生变化，否则DRAM中的比特翻转不会消失。

crotchfire: <i>What about DIMMs with Error Correction Codes (ECC)?
Previous work on DDR3 showed that ECC cannot provide protection against Rowhammer.</i><p>This is incredibly misleading. The paper they cite states:<p><i>When the ECC detection is used correctly 0.65%-7.42% of all bit flips still cause silent corruptions... On setup AMD-1, uncorrectable errors crash the system.</i><p>The attacker will need to cause dozens of machine halts in order to achieve even a single exploitable bitflip. Dozens of machine halts is not something that goes undetected.<p>Kudos for calling out JEDEC's terrible behavior on the rowhammer question, but we should not be downplaying ECC as a near-term solution.

crotchfire: <i> 带纠错码（ECC）的DIMM怎么办？先前对DDR3的研究表明，ECC不能提供针对Rowhammer的保护</i> <p>这是令人难以置信的误导。他们引用的论文指出：＜p＞＜i＞当ECC检测正确使用时，0.65%-7.42%的所有位翻转仍然会导致无声损坏。。。在设置AMD-1时，无法纠正的错误会使系统崩溃</i> <p>攻击者需要导致数十次机器停机，才能实现哪怕是一次可利用的位翻转。数十次机器停机并非未被发现<p> 为喊出JEDEC；在赛艇手问题上的糟糕行为，但我们不应该低估ECC作为近期解决方案的重要性。

VHRanger: Serious question: as an average person, are those hardware security issues (rowhammer, spectre, meltdown) an actual risk?<p>My understanding with spectre and meltdown was that it was an issue for escaping VMs and similar attacks - something AWS engineers should care about, but not me

VHRanger: 严肃的问题：作为一个普通人，这些硬件安全问题（rowhammer、spectre、熔毁）是一个实际的风险吗<p> 我对幽灵和崩溃的理解是，这是一个逃避虚拟机和类似攻击的问题——AWS工程师应该关心，但我不应该

ciupicri: I wonder: does Secure Memory Encryption [1] help against this?<p>[1]: <a href="https://www.amd.com/en/developer/sev.html" rel="nofollow">https://www.amd.com/en/developer/sev.html</a>

ciupicri: 我想知道：安全内存加密[1]有助于解决这个问题吗<p> [1]：<a href=“https://；&#x2F；www.amd.com#xx2F；en&#x2F，developer&#x2F！sev.html”rel=“nofollow”>https://&#x2F；www.amd.com&#x2F；en；显影剂；sev.html</a>

DarkNova6: I know far too little about hardware security. Is this one of the many inevitable vulnerabilities that arise from CPU optimization and are of little feasibility in the real world?

DarkNova6: 我对硬件安全知之甚少。这是CPU优化中不可避免的漏洞之一吗？在现实世界中，这些漏洞几乎不可行？