近年来,硬件安全漏洞频出,基于Cache侧信道攻击的漏洞是典型的体系架构安全威胁,比如影响全球的Spectre[1]、Meltdown[2]、Spoiler[3]等漏洞。目前在软件层面无法完全防御这些硬件漏洞,因此,对于Cache侧信道攻击与具有类似特征的攻击(如Rowhammer[4]攻击)检测分析至关重要。Cache侧信道攻击[5]是指通过访问Cache的时间差异来获取内存中存储的数据。其中Flush-reload[6]是一种典型的Cache侧信道攻击,攻击程序不断访问Cache并清除访问,造成大量的Cache miss。如果在某一时间用户访问过该内存,则对应的数据会被存储到Cache中,而此时攻击程序访问时会发现Cache命中,根据该特点猜测出用户访问的数据,从而得到隐私数据。
Cache侧信道攻击典型的代表是:Prime-Probe[7]、Flush-reload和Flush-flush[8]。本文主要检测并定位具有高Cache miss率的Cache侧信道攻击,例如Flush-reload攻击和具有相同特征Rowhammer攻击等,大部分的硬件漏洞如Spectre和Meltdown都结合了这类攻击。
对于研究人员来说,通常需要对恶意程序进行更细致的研究分析,而对于二进制程序的研究通常是漫长且曲折的;对于代码编写者来说,Cache miss率更是优化的关键,而定位性能低下的代码具体位置却十分困难。
目前,定位主要分为2类:一类是基于源码的静态检测,如Li等[9]提出的利用代码相似性的脆弱性检测的VulPecker,Jovanovic等[10]提出的使用数据流分析进行脆弱性检测的Pixy。另一类是动态检测,如Newsome等[11]提出的TaintCheck,通过动态污点分析追踪输入并传播污点,结合语义分析回溯污点来进行攻击定位;Castro等[12]利用数据流完整性来进行攻击定位;Chen等[13]提出的Ravel,则是通过记录并分析程序内存访问模式来定位攻击。研究发现,Cache侧信道攻击核心的攻击方式是通过循环不停地访问Cache和清除访问,因此本文提出了对于Cache侧信道攻击进行热点循环定位的方法。
循环检测一般分为静态检测和动态检测。静态检测如Xu等[14]对循环不变结构进行检测,Moseley等[15]通过二进制插桩工具Pin进行BBL插桩获取程序循环。文[16-19]提出了动静态结合检测循环的方式,并在CCT(call context tree)[20]基础上,添加循环生成L-CCT(loop-call context tree)的展现方式。
本文提出了在动静态结合的检测方法上过滤系统函数,更精准地还原程序内部结构的循环检测方法。检测Cache侧信道攻击与具有类似特征的攻击; 提出了一种循环检测方式,对二进制程序进行结构分析,还原二进制程序的内部函数和循环结构; 提出了对Cache侧信道攻击进行定位检测的方法,确定了攻击范围,从而方便研究人员针对定位的攻击循环展开研究。根据该方法,代码编写者也能快速定位其程序热点,从而进行性能改进。
1 方案设计与实现 1.1 方案的提出Cache侧信道攻击程序借助循环不断地访问Cache并清除访问,造成大量的Cache miss,导致程序拥有不正常的接近100%的Cache miss率。本文的主要目的是定位不正常的Cache miss发生的循环。此外,针对良性程序来说,定位Cache miss率高的循环也能使得代码编写者精准地对代码进行进一步优化。
为了对Cache侧信道攻击程序进行攻击精确定位,并对性能有待改进的良性程序进行优化定位,本文提出了基于性能分析的Cache侧信道攻击循环定位的方案,其架构如图 1所示。
整体架构分为2个模块,攻击检测和攻击定位模块。在攻击检测模块中,以二进制程序作为输入,进行攻击检测(性能检测)。在攻击定位模块中,对二进制程序进行Cache miss采样分析,记录采样数据,再进行循环和函数检测,最后进行数据分析处理,将内在结构与采样结果进行结合,定位并显示发生攻击的循环位置。
1.2 攻击检测攻击检测是至关重要的第一步,只有判断了一个程序是攻击程序或者是性能待改善的程序,才有必要对其进行攻击定位或是性能改进。对于检测Cache侧信道攻击,近年来,不少研究者都作出了贡献[21-25],虽然形式各不相同,但其本质都是检测程序的Cache miss率。
本文采用父子进程的方式进行检测,在父进程中开启硬件性能计数器,在子进程中运行被测程序,通过父进程来监测子进程运行过程中Cache miss率。HPC (hardware performance counter)[26]是CPU提供的专用寄存器,用于收集程序运行过程中的数据。检测流程如图 2所示。
父进程通过Linux操作系统提供的perf_event_open [27]进行系统调用,初始化CPU中的PMU (performance monitor unit) [28],PMU主要负责管理和监控硬件性能计数器,而通过perf_event_open可以对PMU进行操纵。子进程则运行被检测的程序,父进程通过ioctl系统调用开启PMU,并通过子进程的pid对子进程进行相关事件计数,等待子进程执行完毕,关闭PMU计数,通过read系统调用读取相应的事件计数值,计算Cache miss率,判断是否为攻击程序或是性能待优化的程序。该检测过程只会造成很小的性能开销。
1.3 攻击循环定位在确定程序是攻击程序或性能待优化程序后,对该程序进行定位检测。检测流程如图 3所示,主要分为3部分:采样分析、循环检测和最后的攻击循环定位。以二进制程序为输入,对其进行性能检测得到发生Cache miss时采样击中的指令集。同时,对其进行循环和函数检测,生成LCCT树和循环地址列表。最后将指令集和循环地址列表进行地址匹配,结合LCCT定位攻击循环,生成定位结果图。
1.3.1 采样
对于一个经常发生Cache miss的程序,本文的目标是定位发生Cache miss最多的循环,采用采样的方式来获取程序运行中Cache miss发生最多的指令集。因此采样可以说是攻击定位中最重要也是最有效的一步。
通过perf的record[29]对程序的运行过程中的Cache miss事件进行采样。每隔一段时间,例如设置频率为10 000 Hz,则每隔1/10 000 s产生一次中断,记录此时发生Cache miss事件的指令地址与其他信息,尽可能地设置较高的频率采样,以保证采样数据的正确性。采样完毕后通过perf script导出原始采样数据进行后期的数据处理,导出时必须的核心数据为指令地址,由所属函数调用。在进行后期数据处理时,可以通过发生Cache miss最多的指令的地址集来确定其所属的循环,由于对地址的采样具有偶然性,因此通过多条指令的数据集将定位的范围扩大到了循环,而不是简单的一条指令上。虽然单条指令的定位更为精准,但是容易造成错误。
1.3.2 循环检测获取采样的数据后,需要进一步进行分析处理,结合到循环中。但目前对二进制程序内在结构和循环检测的研究较少,检测的循环也不够完善,因此设计了一种循环检测方法,通过Intel Pin的再编译获取循环大致范围,结合BBL插桩与分支指令判断过滤系统函数与系统函数中的循环,获取代码自身的函数与循环,并通过地址配对转换,获取内部运行结构。
图 3中依旧以二进制程序作为输入,使用Intel Pin[30]插桩工具对二进制程序进行插桩分析,主要分为3个步骤:再编译阶段获取大致循环范围,运行阶段获取实际运行的循环和函数,结束阶段进行数据处理。
首先是Pin的插桩过程,即将需要执行的插桩代码编译后插入到源程序中,称为再编译过程。在此过程中可以通过Pin提供的API[31],根据循环具有负偏移的跳转指令这一特点,在再编译阶段大致获得所有的循环。只获取循环对于展现二进制程序的内在结构并不是一件容易的事,因为光凭循环间的并列调用关系,很难还原二进制程序的原貌,因此本文一并获取了所有的函数调用和返回指令,通过匹配可得函数的起始地址和返回地址。结合循环,生成LCCT树,如图 4c的形式。
再编译完成后,Pin开始运行程序,此时不仅会运行程序本身,也会运行插桩代码,通过插桩可以获取程序更多信息。再编译阶段是对程序汇编代码的分析,因此可能会造成误判的情况,需要在程序的执行过程中进行验证,并且获取循环和函数的执行控制流。根据循环是不断运行同一段代码即其指令地址集是不断重复的这一特点,通过Pin的BBL插桩,将运行过程中所有BBL地址(循环由多个BBL块组成)入栈,如果该地址已存在,并且是上阶段中获取到的循环地址,判断其分支跳转地址,一致则确认其为循环。
最后在程序运行完毕后,Pin会调用finish函数,在此时可以将得到的数据进行处理,并生成LCCT树,其生成过程如图 4a所示;图 4c是最后生成的LCCT树,可以看出对源程序的内在结构进行了完全一致地还原。图 4b是转换过程,为了配对方便,将获取到的运行顺序的地址列表进行转换,将函数起始地址和返回地址都转换成函数名,并在最后添加main构成闭环,将循环结束地址转换成循环起始地址,转换完成后形成了函数循环列表。
将列表从上往下入栈,当入栈元素和原栈顶元素相同时,认为该循环或函数执行完毕,将其出栈,将该节点状态设置和闭合,并将当前指针移动到LCCT树中该节点的父节点。通过不断地配对和指针的移动,最终生成LCCT树。
1.3.3 攻击循环定位获得采样数据和所有循环后,将攻击定位到具体的循环中。采用指令地址和循环地址范围相匹配的方式。将采样数据进行过滤,找出其中占比最大的指令集,即发生Cache miss最多的指令地址集。然后将其与循环地址相匹配,如果大量指令都位于某一循环中,则认定该循环为攻击所在。
循环存在嵌套的可能性,而为了定位的精确性,本文采用了循环控制流的方式进行地址匹配。假设攻击循环为内循环,则需要排除定位到外循环的可能,以免引起歧义。图 4a中,假设攻击发生在Loop 4,则需要排除匹配到Loop 3的可能性。因为就循环地址而言,Loop 3包含Loop 4,那么匹配地址时也会匹配到Loop 3。为了排除这种可能性,使用循环控制流,按循环结束运行的顺序进行排序,即{Loop 2,Loop 4,Loop 1,Loop 3,Loop 5 }。对指令集中的地址进行依次匹配,获取第1个相符的循环后不再进行匹配,保证了定位的精确性。通过这种方式,成功地消除了攻击循环定位的歧义。
2 实验与评估为了证明本文提出的方法能很好地检测恶意程序和良性程序,选取了3个典型的Cache侧信道攻击程序、5个Linux命令、5个应用程序和3个SPEC CPU 2006[32]的程序进行检测。所有实验是在CPU为Intel(R) Core(TM) i5-2400(64 bit, 4 cores with 3.10 GHz)、操作系统为Ubuntu14.04 (3.13.0-24-generic)的计算机上进行的。检测结果如表 1所示,可以看到攻击程序的Cache miss率非常高,接近100%,而良性程序则基本在30%以下,因此本文方法可以很好地区分攻击程序和良性程序。
ID | 被测应用 | Cache miss | Cache access | Cache miss率 | 误报 | 漏报 |
1 | flush-reload | 40 004 260 | 40 017 644 | 0.999 666 | No | No |
2 | spectre | 193 723 | 195 654 | 0.990 131 | No | No |
3 | row-hammer | 423 549 510 | 459 213 005 | 0.922 338 | No | No |
4 | random-chase | 3 600 697 413 | 12 911 572 084 | 0.278 874 | N/A | N/A |
5 | g++ | 2 213 | 7 940 | 0.278 715 | N/A | N/A |
6 | sublime-text | 15 782 | 59 625 | 0.264 688 | N/A | N/A |
7 | ls | 1 592 | 6 394 | 0.248 983 | N/A | N/A |
8 | netcdf | 1 812 | 8 778 | 0.206 425 | N/A | N/A |
9 | hmmer | 2 041 | 10 294 | 0.198 271 | N/A | N/A |
10 | diff | 997 | 5 294 | 0.188 326 | N/A | N/A |
11 | cat | 515 | 3 209 | 0.160 486 | N/A | N/A |
12 | gedit | 820 920 | 6 341 684 | 0.129 448 | N/A | N/A |
13 | objdump | 5 231 | 42 577 | 0.122 860 | N/A | N/A |
14 | bzip2 | 3 619 682 | 60 370 697 | 0.059 957 6 | N/A | N/A |
15 | ps aux | 3 431 | 120 945 | 0.028 368 3 | N/A | N/A |
16 | python3 | 182 460 | 6 685 187 | 0.027 293 2 | N/A | N/A |
在确定攻击程序后,本文对其进行了攻击定位的检测,图 5是最后生成的攻击循环定位的LCCT图,图 6是flush-reload的核心攻击代码,其中第100行调用的probe内联函数中是一段汇编代码,可以参考文[5]中的核心攻击代码,即访问Cache并清除访问。对比图 5可以看出,确实定位到了attackLoop函数中的99行的for循环,证明了本文对Cache侧信道攻击的攻击循环定位。使用perf性能采样检测,并且设置了10 000 Hz的采样频率,可以确保攻击检测的准确性,因此3个攻击程序的攻击循环检测均没有误报和漏报。
3 结论
本文基于Cache侧信道攻击会在循环中不断访问Cache并清除访问而导致大量的Cache miss,提出了基于性能分析的Cache侧信道攻击循环定位检测方法。通过性能采样获得Cache miss发生最多的指令集,结合循环检测获取的二进制程序的内部函数及循环结构,实现Cache侧信道攻击的攻击循环定位。该方法可以方便研究人员在代码中定位Cache侧信道攻击并展开研究;而代码编写人员根据该方法可以一目了然地定位程序热点,从而进行代码性能优化。在今后的研究工作中,可以将其运用到其他有性能特征的攻击或代码优化中。
[1] |
KOCHER P, HORN J, FOGH A, et al. Spectre attacks: Exploiting speculative execution[C]//2019 IEEE Symposium on Security and Privacy (SP). San Francisco, USA: IEEE, 2019: 1-19.
|
[2] |
LIPP M, SCHWARZ M, GRUSS D, et al. Meltdown[J]. arXiv preprint arXiv, 2018: 1801.01207.
|
[3] |
ISLAM S, MOGHIMI A, BRUHNS I, et al. SPOILER: Speculative load hazards boost rowhammer and cache attacks[J]. arXiv preprint arXiv, 2019: 1903.00446.
|
[4] |
SEABORN M, DULLIEN T. Exploiting the DRAM rowhammer bug to gain kernel privileges[Z]. Google Project Zero, 2015.
|
[5] |
TSUNOO Y, SAITO T, SUZAKI T, et al. Cryptanalysis of DES implemented on computers with cache[C]//International Workshop on Cryptographic Hardware and Embedded Systems. Berlin, Germany: Springer, 2003: 62-76.
|
[6] |
YAROM Y, FALKNER K. FLUSH+ RELOAD: A high resolution, low noise, L3 cache side-channel sttack[C]//23rd USENIX Security Symposium. San Diego, USA: USENIX, 2014: 22-25.
|
[7] |
OSVIK D A, SHAMIR A, TROMER E. Cache attacks and countermeasures: The case of AES[C]//Cryptographers' Track at the RSA Conference. Berlin, Germany: Springer, 2006: 1-20.
|
[8] |
GRUSS D, MAURICE C, WAGNER K, et al. Flush+Flush: A fast and stealthy cache attack[C]//International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Cham, Germany: Springer, 2016: 279-299.
|
[9] |
LI Z, ZOU D Q, XU S H, et al. VulPecker: An automated vulnerability detection system based on code similarity analysis[C]//Proceedings of the 32nd Annual Conference on Computer Security Applications. Los Angeles, USA: ACM, 2016: 201-213.
|
[10] |
JOVANOVIC N, KRUEGEL C, KIRDA E. Pixy: A static analysis tool for detecting web application vulnerabilities[C]//2006 IEEE Symposium on Security and Privacy (S&P'06). Berkeley, USA: IEEE, 2006: 263-263.
|
[11] |
NEWSOME J, SONG D X. Dynamic taint analysis for automatic detection, analysis, and signature generation of exploits on commodity software[C]//NDSS Symposium 2005, San Diego, USA: NDSS. 2005: 3-4.
|
[12] |
CASTRO M, COSTA M, HARRIS T. Securing software by enforcing data-flow integrity[C]//Proceedings of the 7th Symposium on Operating Systems Design and Implementation. Berkeley, USA: USENIX Association, 2006: 147-160.
|
[13] |
CHEN Y, KHANDAKER M, WANG Z. Pinpointing vulnerabilities[C]//Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security. New York, USA: ACM, 2017: 334-345.
|
[14] |
XU G Q, YAN D C, ROUNTEV A. Static detection of loop-invariant data structures[C]//European Conference on Object-Oriented Programming. Berlin, Germany: Springer, 2012: 738-763.
|
[15] |
MOSELEY T, GRUNWALD D, CONNORS D A, et al. Loopprof: Dynamic techniques for loop detection and profiling[C/OL].[2019-05-20]. https://www.researchgate.net/profile/Daniel_Connors/publication/249981892_LoopProf_Dynamic_Techniques_for_Loop_Detection_and_Profiling/links/547eb6da0cf2d2200ede9d06.pdf.
|
[16] |
SATO Y, SUZUKI K I, NAKAMURA T. Run-time detection mechanism of nested call-loop structure to monitor the actual execution of codes[C]//2009 Software Technologies for Future Dependable Distributed Systems. Tokyo, Japan: IEEE, 2009: 184-188.
|
[17] |
SATO Y, INOGUCHI Y, NAKAMURA T. On-the-fly detection of precise loop nests across procedures on a dynamic binary translation system[C]//Proceedings of the 8th ACM International Conference on Computing Frontiers. Ischia, Italy: ACM, 2011: 25-26.
|
[18] |
SATO Y, INOGUCHI Y, NAKAMURA T. Whole program data dependence profiling to unveil parallel regions in the dynamic execution[C]//2012 IEEE International Symposium on Workload Characterization (IISWC). La Jolla, USA: IEEE, 2012: 69-80.
|
[19] |
SATO Y, INOGUCHI Y, NAKAMURA T. Identifying program loop nesting structures during execution of machine code[J]. IEICE Transactions on Information and Systems, 2014, 97(9): 2371-2385. |
[20] |
AMMONS G, BALL T, LARUS J R. Exploiting hardware performance counters with flow and context sensitive profiling[J]. ACM SIGPLAN Notices, 1997, 32(5): 85-96. DOI:10.1145/258916.258924 |
[21] |
ZHANG Y Q, JUELS A, OPREA A, et al. HomeAlone: Co-residency detection in the cloud via side-channel analysis[C]//2011 IEEE Symposium on Security and Privacy. Berkeley, USA: IEEE, 2011: 313-328.
|
[22] |
PAYER M. HexPADS: A platform to detect "stealth" attacks[C]//International Symposium on Engineering Secure Software and Systems. Cham, Germany: Springer, 2016: 138-154.
|
[23] |
CHIAPPETTA M, SAVAS E, YILMAZ C. Real time detection of cache-based side-channel attacks using hardware performance counters[J]. Applied Soft Computing, 2016, 49: 1162-1174. DOI:10.1016/j.asoc.2016.09.014 |
[24] |
BAZM M M, SAUTEREAU T, LACOSTE M, et al. Cache-based side-channel attacks detection through intel cache monitoring technology and hardware performance counters[C]//2018 Third International Conference on Fog and Mobile Edge Computing (FMEC). Barcelona, Spain: IEEE, 2018: 7-12.
|
[25] |
MUSHTAQ M, AKRAM A, BHATTI M K, et al. Run-time detection of prime+ probe side-channel attack on AES encryption algorithm[C]//2018 Global Information Infrastructure and Networking Symposium (GIIS). Thessaloniki, Greece: IEEE, 2018: 1-5.
|
[26] |
DE MELO A C. Performance counters on Linux[C]//Presentation at the Linux Plumbers Conference. Lisbon, Portugal, 2009.
|
[27] |
WEAVER V M. Linux perf_event features and overhead[C]//The 2nd International Workshop on Performance Analysis of Workload Optimized Systems. Austin, USA: FastPath, 2013: 13.
|
[28] |
ERANIAN S. Perfmon2: A flexible performance monitoring interface for Linux[C]//Proceedings of the 2006 Ottawa Linux Symposium. Ottawa, Canada Hewlett-Packard Development Company, 2006: 269-288.
|
[29] |
DE MELO A C. The new linux 'perf' tools[C]//Slides from Linux Kongress. Nuremberg, Germany, 2010.
|
[30] |
LUK C K, COHN R, MUTH R, et al. Pin:Building customized program analysis tools with dynamic instrumentation[J]. ACM SIGPLAN Notices, 2005, 40(6): 190-200. DOI:10.1145/1064978.1065034 |
[31] |
INTEL. Pin 3.6 User Guide[R/OL].[2019-5-20]. https://software.intel.com/sites/landingpage/pintool/docs/97554/Pin/html/.
|
[32] |
SPRADLING C D. SPEC CPU2006 benchmark tools[J]. ACM SIGARCH Computer Architecture News, 2007, 35(1): 130-134. DOI:10.1145/1241601.1241625 |