summaryrefslogtreecommitdiff
path: root/chap/chap2.tex
diff options
context:
space:
mode:
Diffstat (limited to 'chap/chap2.tex')
-rw-r--r--chap/chap2.tex427
1 files changed, 411 insertions, 16 deletions
diff --git a/chap/chap2.tex b/chap/chap2.tex
index 5476f01..9a0b39c 100644
--- a/chap/chap2.tex
+++ b/chap/chap2.tex
@@ -396,6 +396,70 @@ Spectre 型攻击利用处理器对控制流或数据流的预测,并进行推
理器预测 load 指令和程序序列之前访问地址未知的 store 指令地址不冲突,
推测式执行这样的 load 指令,它对应 Spectre-STL.
+%%%% gtran: branch prediction
+在推测执行期间,处理器猜测分支指令的可能结果。更好的预测通过增加可成功
+提交的推测性执行操作的数量来提高性能。
+
+现代英特尔处理器的分支预测器,例如Haswell Xeon处理器,具有用于直接和间
+接分支的多种预测机制。间接分支指令可以跳转到在运行时计算的任意目标地址。
+例如,x86指令可以跳转到寄存器,存储器位置或堆栈中的地址,例如“jmp eax”,
+“jmp [eax]”和“ret”。 ARM上也支持间接分支(例如,“MOV pc,r14”),MIPS
+(例如,“jr \$ ra”),RISC-V(例如,“jalr x0,x1,0”)和其他处理器。与直
+接分支相比,为了补偿额外的灵活性,使用至少两种不同的预测机制来优化间接
+跳转和调用[35]。
+
+英特尔[35]描述了处理器的预测
+•以静态或单调方式进行“直接呼叫和跳转”,
+•“间接呼叫和跳转”要么是单调的,要么是以不同的方式,这取决于最近的程序
+行为,以及
+•“条件分支”分支目标以及是否将采用分支。
+
+因此,几个处理器组件用于预测分支的结果。分支目标缓冲区(BTB)保持从最
+近执行的分支指令的地址到目标地址的映射[44]。即使在解码分支指令之前,处
+理器也可以使用BTB来预测未来的代码地址。 Evtyushkin等。 [14]分析了英特
+尔Haswell处理器的BTB,并得出结论,只有31个最低有效位的分支地址用于索引
+BTB。
+
+对于条件分支,记录目标地址对于预测分支的结果不是必需的,因为目的地通常
+在指令中被编码,同时在运行时确定条件。为了改进预测,处理器维护分支结果
+的记录,包括最近的直接和间接分支。 Bhattacharya等。 [9]分析了近期英特
+尔处理器中分支历史预测的结构。
+
+尽管返回指令是一种间接分支,但是在现代CPU中经常使用用于预测目标地址的
+单独机制。返回堆栈缓冲区(RSB)维护最近使用的调用堆栈部分的副本[15]。
+如果RSB中没有可用数据,则不同的处理器将停止执行或使用BTB作为回退[15]。
+
+分支预测逻辑(例如,BTB和RSB)通常不在物理核心之间共享[19]。因此,处理
+器仅从在同一核上执行的先前分支学习。
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+%%%%%%%%%%%%%%%%%%%%%% gtran: attack overview %%%%%%%%%%%%%%%%%%%%%%%5
+
+幽灵攻击诱使受害者推测性地执行在程序指令的严格序列化有序处理期间不会发
+生的操作,并且通过隐蔽通道将受害者的机密信息泄露给对手。我们首先描述利
+用条件分支错误预测的变体(第IV部分),然后利用对间接分支目标的错误预测
+的变体(第V部分)。
+
+在大多数情况下,攻击从设置阶段开始,其中攻击者执行操作以误导处理器,以
+便稍后进行可利用的错误推测预测。此外,设置阶段通常包括有助于引发推测性
+执行的步骤,例如操纵高速缓存状态以移除处理器将确定实际控制流所需的数据。
+在设置阶段期间,攻击者还可以准备将​​用于提取受害者信息的隐蔽信道,例如,
+通过执行刷新或驱逐部分Flush + Reload或Evict + Reload攻击。
+
+在第二阶段期间,处理器推测性地执行将机密信息从受害者上下文传送到微架构
+隐蔽信道的指令。这可以通过让攻击者请求受害者执行动作(例如,通过系统调
+用,套接字或文件)来触发。在其他情况下,攻击者可以利用其自身代码的推测
+(错误)执行来从同一进程获取敏感信息。例如,由解释器,即时编译器或“安
+全”语言沙箱化的攻击代码可能希望读取它不应该访问的内存。虽然推测性执行
+可能会通过广泛的隐蔽通道暴露敏感数据,但给出的示例会导致推测性执行首先
+在攻击者选择的地址读取内存值,然后执行内存操作,以暴露出的方式修改缓存
+状态值。
+
+对于最后阶段,恢复敏感数据。对于使用Flush + Reload或Evict + Reload的
+Spectre攻击,恢复过程包括对正在监视的缓存行中的内存地址的访问进行计时。
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
\subsubsection{Spectre-PHT}
Spectre-PHT 利用分支预测器,攻击者可以训练转移预测器,使得转移预测器执
@@ -409,10 +473,138 @@ if (x < array1_size)
y = array2[array1[x] * 4096];
\end{minted}
-这段程序的 if 条件语句用于判断用户给定的下标 \verb|x| 是否在 array1 界
-内,如果在界外,则无法读取 \verb|array1[x]|. 但是在推测式执行中,瞬时
-指令可以执行读取 \verb|array1[x]| 的操作,并且继续利用读取的值用于访问
-\verb|array2|,导致一个依赖于 \verb|array1[x]| 的地址出现在缓存中。
+
+%%%%%%%%%%%%%%%%%%%%%%% gtran: spectre v1 %%%%%%%%%%%%%%%%%%%%%%%%%%%
+代码片段以对x的边界检查开始,这对于安全性是必不可少的。特别是,此检查
+可防止处理器读取array1外部的敏感内存。否则,越界输入x可能触发异常或者
+可能导致处理器通过提供x =(要读取的秘密字节的地址)来访问敏感存储器 -
+(array1的基址)。
+
+\begin{figure}[htbp]
+ \centering
+ \includegraphics[width=0.8\textwidth]{spectre_v1.eps}
+ \caption{在得出边界检查的正确结果之前,分支预测器使程序从最可能的分
+ 支目标继续运行,如果预测结果正确,则可以得到性能提升。但是,如果边
+ 界检查预测错误,攻击者在一些情形可以泄露秘密数据。}
+ \label{fig:spectre_v1}
+\end{figure}
+
+图1结合推测执行说明了边界检查的四种情况。在已知边界检查的结果之前,CPU
+通过预测比较的最可能结果来推测性地执行该条件之后的代码。有许多原因可能
+导致边界检查的结果不能立即被知道,例如,在边界检查之前或期间的高速缓存
+未命中,边界检查所需的执行单元的拥塞,复杂的算术依赖性或嵌套的推测执行。
+然而,如图所示,在这些情况下对条件的正确预测导致更快的整体执行。
+
+不幸的是,在推测执行期间,边界检查的条件分支可能遵循不正确的路径。在此
+示例中,假设攻击者导致代码运行,使得:
+
+\begin{itemize}
+\item 选择一个恶意越界的 x 的值,使得 \verb|array1[x]| 指向受害者内存中的某个
+ 秘密字节 \verb|k|
+\item \verb|array1_size| 和 \verb|array2| 不在缓存中,但 \verb|k| 在缓存中
+\item 此前的操作中接收到的 \verb|x| 值均有效,使得分支预测器预测 if 为
+ 真
+\end{itemize}
+
+该高速缓存配置可以自然发生或者可以由对手创建,例如,通过导致驱逐
+\verb|array1_size| 和 \verb|array2|,然后让内核在合法操作中使用秘密密钥。
+
+当上面编译的代码运行时,处理器首先将x的恶意值与array1\_size进行比较。读
+取array1\_size导致高速缓存未命中,并且处理器面临相当大的延迟,直到其值
+可从DRAM获得。特别是如果分支条件或分支之前某处的指令等待未缓存的参数,
+则可能需要一些时间才能确定分支结果。与此同时,分支预测器假定if为真。因
+此,推测执行逻辑将x添加到array1的基地址,并从存储器子系统请求结果地址
+处的数据。该读取是高速缓存命中,并快速返回秘密字节k的值。推测执行逻辑
+然后使用k来计算array2 [k * 4096]的地址。然后它发送一个从内存中读取该地
+址的请求(导致缓存未命中)。虽然从array2读取已经在飞行中,但最终可以确
+定分支结果。处理器意识到它的推测执行是错误的并且重新调整其寄存器状态。
+但是,来自array2的推测性读取以特定于地址的方式影响高速缓存状态,其中地
+址取决于k。
+
+为了完成攻击,攻击者测量array2中的哪个位置被带入缓存,例如,通过Flush
++ Reload或Prim + Probe。这揭示了k的值,因为受害者的推测执行缓存了
+array2 [k * 4096]。或者,对手也可以使用Evict + Time,即,使用入境值x'
+立即再次调用目标函数,并测量第二次调用所花费的时间。如果array1 [x']等
+于k,那么在array2中访问的位置在缓存中,并且操作趋于更快。
+
+许多不同的情况可能导致使用此变体的可利用泄漏。例如,代替执行边界检查,
+错误预测的条件分支可以检查先前计算的安全结果或对象类型。类似地,推测性
+地执行的代码可以采用其他形式,例如将比较结果泄漏到固定的存储器位置,或
+者可以分布在更大数量的指令上。上述高速缓存状态也比可能需要的更严格。例
+如,在某些情况下,即使缓存了array1\_size,攻击仍然有效,例如,如果在推
+测执行期间应用分支预测结果,即使比较中涉及的值是已知的。根据处理器,也
+可以在各种情况下启动推测执行。其他变体在第VI节中讨论。
+
+我们在多个x86处理器架构上进行了实验,包括Intel Ivy Bridge(i7-3630QM),
+Intel Haswell(i7-4650U),Intel Broadwell(i7-5650U),Intel Skylake
+(Google云端未指定Xeon,i5-6200U,i7- 6600U,i7-6700K),Intel Kaby
+Lake(i7-7660U)和AMD Ryzen。在所有这些CPU上都观察到了Spectre漏洞。在
+32位和64位模式以及Linux和Windows上都观察到类似的结果。一些基于ARM架构
+的处理器也支持推测性执行[7],以及我们对Qualcomm Snapdragon 835 SoC(带
+有Qualcomm Kyro 280 CPU)和三星Exynos 7420 Octa SoC(带Cortex-A57和
+Cortex-A53)的初始测试CPU)确认这些ARM处理器受到影响。我们还观察到推测
+性执行可以远远超出指令指针。在Haswell i7-4650U上,附录C中的代码(参见
+第IV-B节)可以在'if'语句和访问array1 / array2的行之间的源代码中插入多
+达188条简单指令,这些指令就在下面适合该处理器重排序缓冲区的192个微操作
+(参见第II-B节)。
+
+我们在JavaScript中开发了一个概念验证,并在Google Chrome版本62.0.3202中
+对其进行了测试,该版本允许网站从其运行的进程中读取私有内存。代码如清单
+2所示。
+
+在分支预测器错误引用过程中,索引(通过位操作)设置为范围内值。在最后一
+次迭代中,index被设置为simpleByteArray的越界地址。我们使用变量
+localJunk来确保不优化操作。根据ECMAScript 5.1 Section 11.10 [13],“|
+0”操作将值转换为32位整数,作为JavaScript解释器的优化提示。与其他优化的
+JavaScript引擎一样,V8执行即时编译以将JavaScript转换为机器语言。虚拟操
+作放在清单2中的代码中,以使simpleByteArray.length存储在本地内存中,以
+便在攻击期间将其从缓存中删除。有关D8的结果反汇编输出,请参见清单3。
+
+由于无法从JavaScript访问clflush指令,我们使用缓存逐出[27,51],即,我们
+以某种方式访问​​其他存储器位置,以便之后逐出目标存储器位置。泄漏的结果通
+过probeTable [n * 4096]的缓存状态传递,n∈0..255,因此攻击者必须驱逐这
+256个缓存行。长度参数(JavaScript代码中的simpleByteArray.length和反汇
+编中的[ebp-0xe0])也需要逐出。 JavaScript不提供对rdtscp指令的访问,并
+且Chrome故意降低其高分辨率计时器的准确性以使用performance.now()[62]
+来阻止定时攻击。但是,HTML5的Web Workers功能使创建一个单独的线程变得简
+单,该线程反复递减共享内存位置中的值[24,60]。这种方法产生了一个提供足
+够分辨率的高分辨率计时器。
+
+作为利用条件分支的第三个例子,我们开发了一个可靠的概念验证,它通过滥用
+eBPF(扩展BPF)接口从未修改的Linux内核泄漏内核内存,而没有针对Specter
+的补丁。 eBPF是一个基于伯克利数据包过滤器(BPF)[49]的Linux内核接口,
+可用于各种目的,包括根据数据包内容过滤数据包。 eBPF允许非特权用户在内
+核的上下文中触发解释或JIT编译以及随后执行用户提供的,内核验证的eBPF字
+节码。攻击的基本概念类似于针对JavaScript的攻击概念。
+
+在此次攻击中,我们仅将eBPF代码用于推测性执行的代码。我们在用户空间中使
+用本机代码来获取隐藏的信道信息。这与上面的JavaScript示例不同,后者的两
+个函数都是用脚本语言实现的。为了推测性地访问用户空间内存中依赖于机密的
+位置,我们对内核内存中的数组执行推测性的越界内存访问,其索引足够大,以
+便访问用户空间内存。概念验证假定目标处理器不支持超级用户模式访问保护
+(SMAP)。但是,没有这种假设的攻击也是可能的。它在Intel Xeon Haswell
+E5-1650 v3上进行了测试,它在默认解释模式和eBPF的非默认JIT编译模式下都
+可以使用。在高度优化的实现中,我们能够在此设置中泄漏高达2000B / s。它
+还在AMD PRO A8-9600 R7处理器上进行了测试,它只能在非默认的JIT编译模式
+下工作。我们将调查原因留给未来的工作。
+
+eBPF子系统管理存储在内核内存中的数据结构。用户可以请求创建这些数据结构,
+然后可以从eBPF字节码访问这些数据结构。为了强制执行这些操作的内存安全性,
+内核存储与每个此类数据结构相关联的一些元数据,并对此元数据执行检查。特
+别地,元数据包括数据结构的大小(在创建数据结构时设置一次并用于防止越界
+访问)以及加载到内核中的eBPF程序的引用数量。引用计数跟踪引用数据结构的
+多少eBPF程序正在运行,确保不释放属于数据结构的内存
+加载的eBPF程序引用它。
+
+我们通过滥用错误共享来增加边界检查的延迟与eBPF管理的阵列的长度。内核将
+数组长度和引用计数存储在同一缓存行中,允许攻击者将包含数组长度的缓存行
+移动到处于Modified状态的另一个物理CPU核心(参见[16,53])。这是通过加载
+和丢弃引用另一个物理内核上的eBPF阵列的eBPF程序来完成的,这会导致内核在
+另一个物理内核上递增和递减阵列的引用计数器。这种攻击在Haswell CPU上实
+现了大约5000B / s的泄漏率。
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+
推测式缓冲区溢出(Speculative Buffer Overflow)
\supercite{spec-buffer-overflow} 是 Spectre-PHT 的另一种形式。处理器存
@@ -437,11 +629,83 @@ if (x < len)
\subsubsection{Spectre-BTB}
-Spectre-BTB 利用间接转移,包含的攻击为 Spectre v2. 攻击者寻找受害者地
-址空间中的一个组件(gadget),它可以通过隐蔽信道泄露受害者地址空间中的
-数据。攻击者训练处理器的 BTB 使得受害者的间接转移指令的预测的目标地址
-为该组件的地址,从而受害者推测式执行这个组件的指令。训练 BTB 的过程可
-以在攻击者的地址空间中进行。
+Spectre v2 利用间接转移的推测式执行,用于预测间接转移的主要部件是 BTB,
+因此在分类上称为 Spectre-BTB.
+
+在 Spectre v2 中,攻击者可以对间接转移进行投毒,从而可以利用由此产生的
+转移预测错误,从另一个上下文(如另一进程)中读取任意内存。如果由于缓存
+缺失等原因,需要较长延迟得到间接转移的目标地址,则处理器从此前预测的目
+标地址处进行推测式执行。
+
+\begin{figure}[htbp]
+ \centering
+ \includegraphics[width=0.8\textwidth]{spectre_v2.eps}
+ \caption{转移预测器在攻击者控制的上下文 A 中训练。在上下文 B 中,转移
+ 预测器根据在上下文 A 中的训练结果进行预测,导致处理器跳转至攻击者选
+ 择的目标地址处进行推测式执行,该目标地址处存放着受害者地址空间中
+ 的 Spectre组件。}
+ \label{fig:spectre_v2}
+\end{figure}
+
+攻击者可以用恶意的目标地址训练转移预测器,从而处理器转移到攻击者选择的
+地址进行推测式执行。在图\ref{fig:spectre_v2}中,转移预测器可以在一个上
+下文中训练,在另一个上下文中进行预测。攻击者可以引导受害者推测式执行在
+正确的程序执行中永远不会执行的位置。由于推测性执行带来了可测量的副作
+用,这种攻击对于攻击者来说及其强大,即使在没有可利用的条件分支错误预测
+的情况下,也可以用它泄露受害者的内存。
+
+举一个简单的攻击例子,攻击者试图读取受害者的内存,当发生间接转移时,攻
+击者可以控制两个寄存器。这在现实的二进制程序中很常见,因为操作从外部接
+收数据的函数通常会进行函数调用,此时寄存器包含攻击者控制的值。
+
+攻击者还需要找到一个 Spectre 组件,它是一个用于在推测式执行中,将受害者
+的敏感信息转移到隐蔽通道中的代码片段。在这个例子中,一个有效的组件可以
+由两个指令组成。一个将攻击者控制的 R1 指向的内存加到攻击者控制的寄存
+器R2 上,接下来一个指令用 R2 访问内存。在这种情况下,Spectre 组件可以让
+攻击者通过 R1 控制泄露的地址,以及攻击者通过 R2 控制第二条指令读取泄露
+数据对应的地址。Spectre 组件需要在受害者可执行的内存中,由于大多数进程
+在内存中映射了很大的共享库,攻击者有足够多的空间找到这样的组件,而不需
+要搜索受害者程序的代码。
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% gtran %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+许多其他攻击是可能的,这取决于对手所知道或控制的状态,对手所寻求的信息
+所在的位置(例如,寄存器,堆栈,内存等),对手控制推测执行的能力,指令
+序列可用于形成小工具,以及哪些渠道可能会泄漏来自投机操作的信息。例如,
+如果攻击者可以简单地在将来自寄存器中指定的地址的存储器带入高速缓存的指
+令中诱导推测执行,则在寄存器中返回秘密值的加密函数可能变得可利用。同样,
+尽管上面的示例假设攻击者控制两个寄存器,但攻击者控制单个寄存器,堆栈上
+的值或内存值对于某些小工具来说已足够。
+
+在许多方面,利用类似于面向返回的编程(ROP),除了正确编写的软件易受攻
+击,小工具的持续时间有限但不需要干净地终止(因为CPU最终会识别推测错误)
+和小工具必须通过旁道而不是明确地渗透数据。仍然,推测执行可以执行复杂的
+指令序列,包括从堆栈读取,执行算术,分支(包括多次)和读取存储器。
+
+在x86处理器上模糊分支预测器。
+
+攻击者从其自己的上下文中执行分支预测器的错误操作,以欺骗处理器在运行受
+害者代码时推测性地执行小工具。我们的攻击过程模仿受害者的分支模式导致分
+支被误导。
+
+请注意,历史错误要求因CPU而异。例如,在Haswell i7-4650U上,使用了大约
+29个先前目标地址的低20位,尽管观察到在这些地址上进行了一些进一步的散列。
+在AMD Ryzen上,仅使用大约前9个分支的低12位。附录A中提供了用于更新Intel
+Xeon Haswell E5-1650 v3上的分支历史缓冲区的反向工程伪代码。
+
+此外,我们在攻击者的同一个虚拟地址处设置了一个跳跃,就像在受害者进程中
+一样。注意,这可能不是必需的,例如,如果CPU仅基于跳转地址的低位索引预
+测。在设计分支预测器时,我们只需要模拟虚拟地址;物理地址,时间和进程ID
+似乎并不重要。由于分支预测不受其他内核上的操作的影响(参见第II-C节),
+因此必须在同一CPU内核上进行任何错误训练。
+
+我们还观察到分支预测器从非法目的地的跳跃中学习。虽然在攻击者的进程中触
+发了异常,但这可以很容易地捕获,例如,使用Linux上的信号处理程序或
+Windows上的结构化异常处理。与前一种情况一样,分支预测器然后将进行预测,
+将其他进程发送到相同的目标地址,但是在受害者的虚拟地址空间(即,小工具
+所在的地址空间)中。
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
\subsubsection{Spectre-RSB}
@@ -478,14 +742,145 @@ Prime+Probe 方式进行 Meltdown 和 Spectre 攻击的形式。通过利用缓
\subsection{NetSpectre}
-NetSpectre \supercite{netspectre} 是通过网络使用 Spectre 的攻击方法,
-这种攻击方式将 Spectre 由本地攻击扩展到远程攻击,使得不会运行攻击者控
-制的代码的设备也受到 Spectre 攻击的威胁。
+%%%%%%%%%%%%%%%%%% gtran %%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+迄今为止,在JavaScript [48]和本机代码[15,48,58,75]中已经证明了幽灵攻击,
+但是任何允许足够精确的定时测量和某种形式的代码执行的环境都可能实现这些
+攻击。对英特尔SGX飞地的攻击表明,飞地也容易受到幽灵攻击[15]。但是,有
+数十亿的设备从不运行任何攻击者控制的代码,即没有JavaScript,没有本机代
+码,并且目标系统上没有其他形式的代码执行。到目前为止,这些系统被认为可
+以安全地抵御此类攻击。事实上,供应商确信这些系统仍然是安全的,并建议不
+要对这些设备采取任何措施[42]。
+
+在本文中,我们提出NetSpectre,一种基于Spectre变体1的新攻击,不需要攻击
+者控制的代码
+设备,从而影响数十亿设备。与本地Spectre攻击类似,我们的远程攻击要求目
+标代码中存在Spectre小工具。我们展示了在暴露的网络接口或API中包含所需
+Spectre小工具的系统可能受到我们的通用远程Specter攻击的攻击,允许通过网
+络读取任意内存。攻击者只向受害者发送一系列精心设计的请求,并测量从受害
+者的记忆中泄漏秘密值的响应时间。
+
+我们表明,内存访问延迟通常可以反映在网络请求的延迟中。因此,我们证明了
+攻击者可以通过测量和平均大量测量来远程区分特定高速缓存行上的高速缓存命
+中和未命中。基于此,我们实施了第一个访问驱动的远程缓存攻击,一个名为
+Thrash + Reload的Evict + Reload的远程变体。我们的远程Thrash + Reload攻
+击是先前对加密算法的远程缓存定时攻击的重大飞跃[1,5,11,16,46,82]。我们
+推动这种技术将现有的Spectre攻击改造为基于网络的场景。此NetSpectre变体
+每小时可从易受攻击的目标系统泄漏15位。
+
+通过利用基于AVX2指令执行时间的先前未知的侧通道,我们还演示了第一个完全
+不依赖于缓存隐藏通道的Spectre攻击。我们基于AVX的隐蔽通道实现了每秒125
+字节的本机代码性能,错误率为0.58%。通过在我们的NetSpectre攻击中使用此
+隐蔽通道而不是缓存隐藏通道,我们可以实现更高的性能。由于不再需要高速缓
+存驱逐,因此我们将局域网中目标系统的泄漏速度提高到每小时60位。在Google
+云中,我们每小时可以从另一台独立虚拟机泄漏大约3位。
+
+我们证明使用先前忽略的小工具可以在远程攻击中破坏地址空间布局随机化。
+地址空间布局随机化(ASLR)是当今部署在大多数系统上的防御机制,几乎所有
+地址都是随机的。具有本地代码执行功能的攻击者可以轻松绕过ASLR,因为ASLR
+主要用于防御远程攻击
+但不是本地攻击。因此,到目前为止,Spectre攻击的许多较弱的小工具都被忽
+略了,因为它们不允许泄漏实际数据,而只是泄漏地址信息。但是,转向远程攻
+击情形,这些较弱的小工具变得非常强大。
+
+幽灵小工具可能比以前的工作更加通用。这不仅体现在我们在远程ASLR中断时使
+用的较弱的小工具,而且我们提出的价值阈值技术更是如此。值阈值不使用典型
+的位选择和内存参考机制,如之前的Spectre攻击所示。相反,价值阈值通过使
+用类似于二元搜索的分而治之的方法直接利用比较中的信息泄漏。
+
+NetSpectre标志着从本地攻击到远程攻击的范式转变。这显着扩大了范围并增加
+了受影响设备的数量。特别是,Spectre攻击还必须被视为对不运行任何不受信
+任的攻击者控制代码的设备的安全性的威胁。这表明反措施也必须适用于以前认
+为安全的这些设备。我们提出了Retpolines [77]的新替代品,它具有更清晰的
+结构。关于幽灵攻击和幽灵缓解的未来研究面临着我们概述的一系列挑战。这些
+挑战表明,目前的防御措施只能是临时解决方案,因为它们只能解决症状而不解
+决问题的根本原因。
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+%%%%%%%%%%%%%%%%% gtran %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+在知道实际条件之前,CPU预测条件的最可能结果,然后继续相应的代码路径。
+有几个原因导致在评估时不知道条件的结果,例如条件的部分缓存未命中,尚未
+满足的复杂依赖性,或者所需执行单元中的瓶颈。通过隐藏这些延迟,如果条件
+被正确预测,推测执行会导致更快的整体执行。错误预测条件的中间结果根本不
+会提交到架构状态,并且有效性能类似于处理器永远不会执行任何操作然而,在
+推测性执行期间发生的微体系结构状态的任何修改(例如高速缓存状态)都不会
+被还原。
+
+由于我们的NetSpectre攻击是通过网络安装的,因此受害设备需要攻击者可以访
+问的网络接口。攻击者必须能够向受害者发送大量网络数据包。但是,这些不一
+定必须在其中
+很短的时间。此外,我们攻击中的数据包内容不需要受攻击者控制。
+
+与本地幽灵攻击相比,我们的NetSpectre攻击并没有分为两个阶段。相反,攻击
+者不断执行操作以使处理器出错,这将使其经常遇到可利用的错误推测执行。
+NetSpectre不会跨越进程边界,而是通过将有效和无效值交替地传递给暴露的接
+口(例如,有效和无效的网络数据包)来就地进行训练。对于我们的NetSpectre
+攻击,攻击者需要两个Spectre小工具,如果收到网络数据包,则会执行这些小
+工具:泄漏小工具和传输小工具。泄漏小工具在攻击者控制的索引处访问位流,
+并根据所访问位的状态改变一些微架构状态。传输小工具执行任意操作,其中运
+行时取决于泄漏小工具修改的微架构状态。在大量噪声中,攻击者可以观察到网
+络数据包响应时间的这种时序差异。 Spectre小工具常见于现代网络驱动程序,
+网络堆栈和网络服务实现中。
+
+为了说明我们的NetSpectre攻击的工作原理,我们在一个适应的场景中考虑一个
+类似于原始Specter变体1示例[48]的基本示例:清单1中的代码是在收到网络数
+据包时执行的函数的一部分。我们假设x是攻击者控制的,例如,包头中的字段
+或某些API的索引。此代码构成我们的泄漏小工具。
+
+\begin{minted}{C}
+if (x < bitstream_length)
+ if (bitstream[x])
+ flag = true;
+\end{minted}
+
+ 代码片段以x的绑定检查开始,这是开发安全软件时的最佳实践。特别是,该
+ 检查防止处理器读取比特流之外的敏感存储器。否则,越界输入x可能触发异
+ 常或者可能通过提供x =(要读取的秘密位的地址) - (比特流的基地址)来
+ 使处理器访问敏感存储器。
+
+ 为了利用远程攻击中推测性执行期间的微体系结构状态变化,攻击者必须适应
+ 原始的幽灵攻击。攻击者可以远程诱导推测性执行,如下所示:
+
+ (1)攻击者发送多个网络数据包,使得攻击者选择的x值总是在边界内。这会
+ 训练分支预测器,增加分支预测器预测比较结果为真的机会。
+ (2)攻击者发送一个数据包,其中x超出界限,使得比特流[x]是目标存储器
+ 中的一个秘密位。
+ (3)根据条件的最近分支结果,分支预测器假定边界检查为真,并且推测性
+ 地执行存储器访问。
+
+ 虽然在解决了条件的正确结果后未提交架构状态的更改,但不会还原微架构状
+ 态的更改。在清单1的代码中,这意味着虽然flag的值没有改变,但是flag的
+ 缓存状态确实发生了变化。仅当设置了比特流[x]处的秘密比特时,才缓存标
+ 志。
+
+ 传输小工具更简单,因为它只需要在任意操作中使用标志。因此,小工具的执
+ 行时间将取决于标志的高速缓存状态。在最简单的情况下,传输小工具只返回
+ flag的值,该值由泄漏小工具设置。由于标志的架构状态(即其值)对于越界
+ x不会改变,因此它不会泄露秘密信息。但是,发送小工具的响应时间取决于
+ 标志的微体系结构状态(即,是否被高速缓存),这确实泄漏了一个秘密位。
+
+ 为了完成攻击,攻击者测量每个秘密位泄漏的响应时间。由于响应时间的差异
+ 在纳秒范围内,攻击者需要对大量测量进行平均以获得具有可接受置信度的秘
+ 密值。实际上,我们的实验表明,在进行大量测量时,微结构状态的差异变得
+ 明显。因此,攻击者可以首先测量两个角落情况(即,缓存和未缓存)和之后,
+ 以提取真实秘密位,执行尽可能多的测量以区分具有足够置信度的情况,例如,
+ 使用阈值或贝叶斯分类器。
+
+ 我们将这两个小工具,即泄漏小工具和传输小工具称为NetSpectre小工具。运
+ 行NetSpectre小工具可能需要发送多个数据包。此外,泄漏小工具和传输小工
+ 具可以通过不同的独立接口来访问,即,攻击者必须可以访问这两个接口。
+
+\begin{figure}[htbp]
+ \centering
+ \includegraphics[width=0.8\textwidth]{netspectre.eps}
+ \caption{NetSpectre 的泄露组件和传输组件}
+ \label{fig:spectre_v2}
+\end{figure}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-在 NetSpectre 攻击中,攻击者利用两中 NetSpectre 组件,一个是泄露组件
-(leak gadget),通过改变微架构状态,泄露秘密数据;一个是传送组件
-(transmit gadget),它将微架构状态的改变通过网络传送给攻击者,攻击者
-可以通过网络数据包的延迟,推断出微架构状态,从而获取秘密数据。
NetSpectre 可以在局域网,或者 Google cloud 等云平台中使用。利用
Evict+Reload 缓存信道,每小时可以泄露 15 比特。利用基于 AVX 的隐蔽信道,