独家:AMD EPYC 处理器有问题,但公司不想知道
温馨提示:这篇文章已超过1013天没有更新,请注意相关的内容是否还可用!
去年,我们报告了一个漏洞,该漏洞可能允许攻击者绕过 AMD 的EPYC服务器处理器中的安全加密虚拟化(SEV) 技术提供的保护。
当问题曝光后,AMD 驳回了该漏洞利用,理由是它需要物理访问硬件,但这只是故事的一半。负责最初发现的研究人员罗伯特·布伦(Robert Buhren)表示,只有在第一次情况下才需要物理访问,之后可以远程利用该漏洞造成灾难性影响。
然而,从那时起,另一位名为 Atul Payapilly 的安全专家为该漏洞设计了一种解决方法,他说该漏洞可以关闭远程攻击向量并保留 AMD SEV 的实用程序。唯一的问题是,AMD 对听到它不感兴趣。
为什么这有关系?
AMD SEV 漏洞的核心是一种称为远程证明的机制,云客户可以借此验证其虚拟机的正确部署。
远程认证能否按预期发挥作用取决于芯片背书密钥 (CEK) 的安全性,CEK 是每个 EPYC 处理器所独有的,并充当信任根。如果任何 AMD EYPC 背书密钥被攻击者破坏,AMD SEV 在所有部署中提供的保护将变得毫无意义,因为密钥是可互换的。
最初的研究人员发现,通过操纵通过 EPYC SoC 的电压,可能会在 AMD 安全处理器 (AMD-SP) 的只读存储器 (ROM) 引导加载程序中引发错误,从而释放最重要的 CEK。这种攻击可以在公开市场上购买的芯片上进行,这意味着攻击者不必渗透部署在生产环境中的硬件。
当该漏洞在 Black Hat 上展示时,Buhren 声称该问题没有任何缓解措施,他说只能在未来几代 EPYC 处理器中纠正。
这种情况的后果是多种多样的。实际上,这意味着任何希望在 AMD SEV 之上构建服务的公司都必须立即停止其计划,并等待今年晚些时候 EYPC Genoa 芯片的到来——这是假设下一代芯片提供了修复。
Payapilly 之所以开始调查这个问题,首先是因为他发现自己恰好处于这个位置。他的公司 Verifiably 使用可信执行环境来证明代码的完整性。然而,现在 AMD SEV 的安全性受到质疑,该公司无法真诚地利用该技术来支持其预期的产品。
解决方案
Payapilly 不相信不等待新硬件上市就无法解决 AMD SEV 漏洞的说法,于是开始寻找解决方案。
他设计的解决方法是建立在这样一个原则之上的:是时候接受硬件安全性永远无法得到保证了。因此,我们需要能够降低这种风险的基于软件的解决方案。
所提出的解决方案旨在消除远程攻击向量,通过解决目前无法判断哪个芯片背书密钥 (CEK) 已被泄露的事实,直到发生滥用。可以总结如下:
- 云提供商使用从其部署的每个 AMD EYPC 处理器中提取的 CEK 填充白名单
- 当客户执行远程证明时,云提供商会对其可信密钥列表进行交叉检查
- 在最终发布信息之前,查询被传递给 AMD 以针对根密钥进行签名
Buhren 单独确认了该变通办法的有效性,尽管他急于强调这并不是对原始攻击的缓解措施。他还指出,解决方法将要求客户信任他们的云提供商。
尽管 AMD 本身不需要任何东西,但为了将解决方案付诸实践,Payapilly 表示,公司将从与云提供商合作实施缓解措施中受益。然而,到目前为止,AMD 并没有表现出这样做的兴趣。
Payapilly 最初是在 2 月 14 日那一周联系了该公司,但没有回复。3 月 8 日,AMD 告诉TechRadar Pro,它不会评论远程利用该漏洞的机会、提议的解决方法或解决未来几代 EYPC 处理器问题的计划。
九七分享吧所有文章来源于网络收集整理,如有侵权请联系QQ2387153712删除,如果这篇文章对你有帮助或者还不错的请给小编点个小赞(◠‿◠),小编每天整理文章不容易(ಥ_ಥ)!!!
还没有评论,来说两句吧...