如何防止黑客幽灵般洪水袭击

　　中国黑客教父郭盛华教你如何防止黑客幽灵般的攻击：尘埃落定于对“幽灵”和“熔毁”的最初反应。崩溃是相对简单的处理; 我们可以认为它是固定的。幽灵要困难得多，对软件生态系统有着深远的影响。 

　　社区将Specter视为两个不同的问题，“变体1”涉及在条件分支之后推测性地执行的代码，“变体2”涉及通过间接分支推测性地执行代码，其预测目的地是由攻击者控制的。他希望这些有更好的名字，如Cest la vie。

 幽灵变种1缓解

　　Webkit，Linux内核和Microsoft出现了减轻变体1的建议。前两者提出了类似的想法：屏蔽数组索引，以至于即使是推测性的数组加载也不能加载超出界限。MSVC采取不同的方法，引入LFENCE指令来阻止推测执行时，加载地址似乎被范围检查保护。不幸的是微软说重要的是要注意，MSVC和编译器在尝试识别变体1的实例时一般可以执行的分析是有限制的。因此，不能保证变体1的所有可能实例将被安装在/ Qspectre下。

　　这似乎是一个很大的弱点，因为开发者不知道这种缓解是否对他们的代码实际上有效。Webkit和Linux内核方法具有可预测的优点，但代价是需要手动更改代码。基本的问题是，在C / C ++中，编译器通常不确定与数组查找相关的数组长度，因此必须手动引入掩码。Webkit进一步发展，增加了防止动态类型检查保护的推测性负载，但是由于C / C ++没有内置的带标签的联合类型，因此必须在许多情况下手动完成。

　　黑客教父郭盛华认为像Rust这样的“安全”语言应该概括Webkit缓解背后的思想：要求投机执行的代码遵守类型系统强加的内存安全约束。这会让幽灵变种1更难以被利用。它包含了我迄今为止所见到的每一个变体1的缓解，并且可以是安全代码的自动化。不安全的防锈代码将需要更新。话虽如此，可能会有变种1攻击，不规避类型系统，这些缓解措施都不会阻止。考虑一下运行JS代码的浏览器：

让x = bigArray [iframeElem.contentWindow.someProperty];

可以想象，可以编译为JIT代码和C ++的混合

  if（iframeElemOrigin == selfDocumentOrigin）{

    index = ...获取someProperty ...

    x = bigArray [index];

  } else {

    错误...

  }

　　推测执行的代码违反了没有类型系统不变量，但可能泄漏属性的价值跨越原点。这个例子表明，针对Specter版本1的完整保护需要严格的缓解措施，无论是普及的和昂贵的代码工具，还是深入的（可能是容易出错的）分析。 

幽灵变种2缓解

　　黑客教父郭盛华表示，这里有两种方法，一个是微代码和硅片更改为CPU，以实现间接分支预测器的刷新和/或禁用。另一个是“retpolines” - 用一个不触发间接分支预测器的指令序列替换间接分支。显然，Linux社区建议所有编译器和汇编编写者避免在用户空间中的所有间接分支。这意味着，例如，我们应该更新rr的手写汇编以避免间接分支。另一方面，微软并没有给出这样的建议，显然也没有计划在MSVC中引入retpoline支持。我不知道为什么这种差异正在发生。

　　假设遵循Linux社区的建议，事情变得更加复杂。未来的CPU可以对变种2进行保护，而不需要转播。出于性能方面的考虑，我们希望避免在这些CPU上进行转播。此外，英特尔未来的CET控制流程完整性硬件将无法使用转播视频，因此我们需要关闭转播视频以确保安全！所以软件将需要在运行时确定是否应该使用反潜节目。JIT和手写汇编将需要添加代码来做到这一点。很长时间以来，这将成为很多软件开发者的负担。

安全/性能权衡

　　现在运行不受信任的代码会有明显的性能损失。如果您确定在（虚拟）机器上没有运行恶意代码，则可以关闭这些缓解措施，并获得显着的性能优势。这以前并不真实。（Unikernels获得了一些性能上的好处，但创造了太多的其他问题，通常是有用的。）盘点虚拟机中运行的整个软件集合，以验证它是所有

　　可信的，可能在实践中很难实现，并减少纵深防御...但毫无疑问，人们会试图做到这一点。我们可以看到对Gentoo等基于源代码的分发的兴趣增加。重新编译您的软件堆栈以包含所需的缓解措施可以带来性能优势。

JAVASCRIPT的影响

　　Javascript和浏览器内容进程的本地代码之间的隔离边界对于CPU而言是不可见的，这使得硬件缓解难以用于JS，以及在同一进程中运行代码的其他系统具有不同的信任级别。很难说这是什么直接的影响，但我认为它使浏览器中的“每个进程的一个站点”策略在长期内更具吸引力，至少作为部署的一个选择，

　　以防万一未来难以缓解的漏洞命中。现在，浏览器正试图通过使JS难以从定时通道中提取信息（通过限制定时器分辨率和禁用像SharedArrayBuffer这样的功能来实现高分辨率定时器）而使问题变得易于管理，但不幸的是这限制了Web应用程序与本地应用程序的能力。例如，只要持续下去，我们就无法通过WebAssembly在浏览器中运行惯用的并行Rust代码.-另外我怀疑在中期攻击者会发现其他读取定时通道的方法，这些方法不太可行。

 　　黑客教父郭盛华认为放弃在同一个地址空间中混合不同信任标签的代码是一个严重的错误。除了必须重新设计大量的软件之外，这将会在信任区域之间转换的成本设定一个硬性下限。如果可以将硬件缓解设计为在单个地址空间内可用，那将会好得多。

其他攻击

　　也许最大的问题是，我们是否看到了基于类似幽灵般的想法的洪水严重袭击的开始。我认为这是完全可能的，如果是这样的话，那么当他们面对这些零星的攻击时，将会是非常昂贵和痛苦的。当缓解措施相互干扰时，缓解措施的成本甚至有可能会增加，越来越少的人能够理解正在发生的事情。因此，我希望并祈祷那些处于权力地位的人--CPU供应商，大型软件供应商等 - 共同努力提出全面的，预防性的解决方案，简单地排除这些类别的攻击，不要让自己完全被消费者要求立即回应零日漏洞。我鼓掌的感情RISC-V为此发表的声明，就是自我服务。

原文地址：http://vm888.com/showinfo-25-6116-0.html

文章由东方联盟原创，抄袭必究，转载请注明