Spectre攻击变种：Spectre 1.1（ CVE-2018-3693）和Spectre 1.2
导语：来自麻省理工大学的 Vladimir Kiriansky 和咨询公司的 Carl Waldspurger 两位安全研究人员，发现了两个“幽灵”（Spectre）安全漏洞新变种，分别是Spectre 1.1（ CVE-2018-3693）和Spectre 1.2。
与之前的Meltdown和Spectre CPU漏洞变种类似，Spectre 1.1和Spectre 1.2也利用了推测执行过程。
Spectre 1.1和Spectre 1.2简介
Spectre 1.1
Spectre 1.1攻击使用了推测执行来传播能造成CPU缓冲区溢出的代码，缓冲区溢出会导致能从之前安全的CPU存储区域内提取数据的恶意代码执行。
Spectre 1.1与之前的Spectre变种1和4非常相似，但研究人员称截止目前，没有有效的静态分析或编译工具能够检测或者缓解Spectre 1.1。
Spectre 1.2
Spectre3.0（Meltdown）是依赖页表记录（page-table entries，PTE）的User/Supervisor protection标记的lazy enforcement（延迟执行）。同样的机制也可以用来绕过Read/Write PTE标记。Spectre 1.2就是依赖Lazy PTE强制执行的Spectrev1变种。在Spectre 1.2攻击中，推测存储可以用来覆写只读数据、代码指针、代码元数据等。即攻击者利用Spectre 1.2漏洞可以向CPU内存区中只读标记的区域写操作。也就是说，Spectre 1.2漏洞使基于硬件的沙箱技术失效了。
与之前发现的Meltdown和Spectre漏洞类似，这两个漏洞都需要用户设备上存在运行攻击所需的恶意代码。但这一定程度上限制了bug的严重性。
影响
漏洞主要影响Intel和ARM芯片，AMD芯片好像也受影响。Intel和ARM已经公开承认部分CPU存在Spectre 1.1漏洞，但AMD并未发布相关声明，不过AMD在安全问题上反应一直比较慢。因为所有的Spectre攻击都影响AMD CPU，所以可以推测新的Spectre漏洞也影响AMD芯片。
研究人员没有透露关于Spectre 1.2影响到CPU的信息。而且目前对这两个漏洞，还都没有发布补丁。
缓解措施
Microsoft、Oracle、Red Hat说他们也在分析Spectre 1.1漏洞是否影响各自厂家产品所处理的数据，也在研究软件级缓解问题的方法。
文章中一共提出三种应对Spectre 1.1攻击的硬件级的缓解措施。具体如下
Store-to-Load Blocking
这种拦截方法希望通过对当前芯片的微代码的更新来预防store-to-load forwarding到推测的存储或加载。这种微代码上实施的可能性是未知的，如果这样方法在很小复杂性的情况下是可行的，就可以在最小可信计算基（minimum trusted computing base，TCB）上提供最大的安全性。
这种方法可以对未打补丁的软件做出最快的响应，可以教软件开发者如何寻找有漏洞的代码。总的来说，这种方法在性能可接受的情况下是非常安全的。
Lazy Store-to-Load Forwarding
这种方法使用的低复杂性和小TCB是非常有吸引力的。而且就算软件不做改变的话，性能也是可以接受的。通过对编译器的再次设计，可以获取最优的性能。
Frozen Store-to-Load Forwarding
如果易出错的软件解决方案是推测执行攻击的唯一可选方案，那么需要做的就是设计更高性能的硬件。Arctic Sloth方法使用了动态检测要转发的store and load对的方法。一个更简单的变种可以记录之前在正确路径上需要的store-to-load forwarding的load指令，并且接受来自任意存储的数据。
这就需要一种更强的硬件地址推测机制，与高性能的Alpha处理器类似，这可能会对增加当前处理器的复杂度、功耗等。
附Spectre攻击变种情况：
