Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

A Software Approach to Defeating Side Channels in Last-Level Caches

  • 作者:Ziqiao Zhou, Michael K.Reiter, Yinqian Zhang
  • 单位:University of North Carolina, Ohio State University
  • 出处:CCS’16

论文下载

概要:

  • 作者提供了一种基于软件的方法来防御针对Last-Level Cache的access-driven 旁路攻击。
  • 这种方法基于安全域动态的管理物理页,禁止LLC 在不同行的物理页共享来防护FLUSH-RELOAD攻击,同时,通过控制单个安全域内的所有进程cache使用能力来防御PRIME-PROBE攻击。
  • 作者在Linux mainline 进行修改,实现了工具CacheBar。

1.介绍

  • Access-driven 旁路攻击是在不违反系统软件隔离的情况下,通过利用攻击者的计算能力,窃取同一台计算机上的秘密信息的攻击。
  • 在LLC上,这种攻击主要分成两类。
    • 第一类是FLUSH-RELOAD攻击,它要求攻击者和victim间存在物理页的共享。攻击者首先清空部分cache,接着执行victim进程,最后通过访问被清空cache所对应的物理页,来检测这部分页面是否被victim使用到。
    • 第二类是PRIME-PROBE攻击。攻击者首先在cache中填充满自己进程内存的数据。接着运行victim进程,通过PROBE先前载入的数据来查看哪些cache因为和victim的冲突被刷掉了。

COA For FLUSH-RELOAD Defense

Design

  • 在现代操作系统上,大多实现了按需配页和COW机制来减少应用级的内存拷贝。而这种内存共享是让FLUSH-RELOAD攻击得以实现的关键因素。
  • 作者在CacheBAR中基于安全域实现了一个COA机制,使得物理页共享只发生在同一个安全域中。
  • CachBAR给每个页4个状态UNMAPPED,EXCLUSIVE,SHARED和ACCESSED。当一个页面处于ACCESSED状态时,却被不同安全域的另一个进程访问,这页物理页会被拷贝,而latter 进程只能访问新拷贝的物理页。

Fig

Implementation

在实现上,主要分为四个部分,第一部分是在PID命名空间中添加了per Secuirty Domain per page 已经mapped了该物理页的进程个数。这个数组可以决定物理页的UMAPPED,EXCLUSIVE,SHARED状态。

Fig

第二部分是在struct page中实现的两个新链表,orignal_struct和 copy_struct。copy_struct中的owner指针决定了是SHARED还是ACCESSED。

Fig

第三部分是一个新的 page fault handler。在PTE中,状态为SHARED和ACCESSED的物理页会被设置COA bit,对它们的访问会触发page fault。

最后一部分是一个daemon ,定时的遍历original list,将最近没有被访问到的page 状态从ACCESSED变为SHARED,来减少不必要的COA。

作者在实现时还考虑到了KSM等page deduplication 机制。例如在下图中,将page5 merge to 7后,page5 会被unmap而page7的状态会变成SHARED。

Fig

Security

  • 安全性验证上作者采用了novel的system modeling的方法。
  • 作者在PROMELA语言中用一个byte表示一个物理页,page[virt]=0代表对应的物理页不在cache中,为1时在cache中。
  • 作者模拟了两个安全域的进程公用一个物理页的情况,开始时virt1=virt2=0,代表两个进程mapped了同一页,此时该页处于SHARED状态,按照设计的模型,当一个ACCESSED状态的物理页被另一进程access时,后者的virt就会变成一个新的值,代表COA拷贝了一个新的物理页。利用这个模型作者进行了模拟,找到了daemon和KSM导致的两个leakage。是由daemon或KSM将ACCESSED状态的页变为SHARED状态后攻击者发动RELOAD,此时由于处于SHARED状态且物理页在cache中,RELOAD攻击可以利用time side channel产生infomation leak。

Fig

Cacheability Management For PRIME-PROBE Defense

Design

另一种常见的攻击方法是PRIME-PROBE攻击。攻击者首先填充满cache set,让victim来冲刷掉cache中的lines,攻击者利用对相同内存的第二次访问时间来估算cache是否被洗刷掉了。CacheBAR在此的 countermeasure是禁止攻击者对整个cache set都拥有使用权限。

对于一个w-way cache,CacheBar给每个安全域分配一个随机数字ka作为能使用的cache set lines的个数(ki < w)。假设对于某个specific way,victim有d lines的需求,有三个因素会使攻击者无法准确评估d的大小。首先。如果ka < w-d,那么攻击者将完全无法看见任何eviction的发生。第二,如果前面的条件不满足,victim能使用的cache set lines为kv,那么攻击者无法区分demand为d还是的(d > d’ >= kv$)。最后,攻击者还需要确定victim的kv。

Implementation

在实现上,CacheBAR利用了PTE中一个reserved bit来表示该页是否是No-Domain的公共页。在此基础上,对于Domain-specific的页,为了保证最多只有ki lines的cache能被使用,CacheBAR对每个安全域能被cache的物理页个数进行了限定。由于同一个页上的内存会按照block大小cache到不同的cache set,所以限制能cache的物理页个数即限制了能使用的cache set lines。(在Linux中,可以在PTE中设置某些位控制该页能否被cache)

Fig

CacheBAR为每个安全域实现了一个队列,在一个有NC位的页发生page fault时,如果队列未满,就会执行一个入队的操作,如果队列已经满了,就会驱逐掉一个物理页。用clflush指令清除那一页的所有cache,并且清空TLB表,确保PTE得到更新。

同样,有一个daemon来负责动态的更新每个安全域的ki,并且根据页面的访问情况重排序队列。

Security

这里作者用了概率分析的方法来分析这种设计的安全性和对应情况下K的随机分布。

Evaluation

作者在一台有2个2.67GHZ Intel Xeon 5550 处理器的DELL服务器进行测试。CacheBAR修改的内核版本位3.13.11.6,系统使用Ubuntu14.04。利用Docker实现容器也就是安全域。

安全性验证

对于FLUSH-RELOAD攻击。作者在两个安全域中分别安置sender和receiver进程,共享一个库-libcrypto.so.1.0.0。sender不停地访问一个物理内存地址,而receiver在同一个物理内存地址进行FLUSH-RELOAD攻击。FLUSH和RELOAD的时间间隔位2500cycles,进行了50万次攻击。获得了一个访问时间的平均值。

可与看得出来开了CacheBar后unshared和shared的访问时间差很相近了。

Fig

对于PRIME-PROBE攻击。同样也使用两个进程,一个执行PRIME-PROBE攻击,另一在每次攻击间隔时执行d次内存访问。在测试机上w=16,ki取值范围为4-14,攻击者的目标为获知victim的demand d范围,简化将其分为6类:NONE={0},ONE={1},FEW={2,3,4},SOME={5,6,7,8},LOTS={9,10,11,12},MOST={13,14,15,16},攻击者有能力知道ka,但不知道kv。作者同样进行了50万次测试,并根据结果训练了两个朴素贝叶斯分类器。然后作者再进行了50万次测试作为测试集,得到了一个混淆矩阵如下

Fig

Fig

再开了CacheBAR后,预测不仅准确度有下降,有些错误更加离谱了。

然后下面是在不同的kv,ka设置下的总的准确率表。

Fig

最后作者对性能进行了相关测试。将开启了CacheBAR和没有修改的内核作性能上的比较。第一个测试在Apache 2.4.7web服务器上,使用PHP-FPM并开启了SSL。每个服务器对应一个client,重复的访问一个内容大小为86kb的网页。

从图中可以看出来对于最大流量的影响是很小的,而对于响应时间则会有20%的overhead。

然后作者对不同服务器应用语言配置做了测试。对每个测试开了16个container,页面大小为80KB,最差的情况是在Python+apache+cgi时产生,有25%的流量overhead。

最后作者对更加复杂的情况进行了模拟。使用nginx+php搭建了一个社区网站。利用Faban生成不同的请求测试响应时间,对于一些注册操作,响应时间的影响还是比较大的,overhead达到了30%多。同时测试了对流行的流媒体服务产生的响应时间的影响,在流媒体服务上响应时间基本就没有影响了。

Fig