2017, Vol. 63
文章信息
- 严飞, 彭慧容, 何凡, 黄凡
- YAN Fei, PENG Huirong, HE Fan, HUANG Fan
- HBROP：基于硬件性能计数器的函数级ROP检测
- HBROP: HPC-Based Function-Level Approach to Detect ROP Attack
- 武汉大学学报(理学版), 2017, 63(2): 109-116
- Journal of Wuhan University(Natural Science Edition), 2017, 63(2): 109-116
- http://dx.doi.org/10.14188/j.1671-8836.2017.02.003
-
文章历史
- 收稿日期：2016-09-30
引用本文
|
2. 武汉大学 计算机学院，湖北 武汉 430072;
3. 武汉理工大学 计算机科学与技术学院，湖北 武汉 430070
2. School of Computer, Wuhan University, Wuhan 430072, Hubei, China;
3. School of Computer Science and Technology, Wuhan University of Technology, Wuhan 430070, Hubei, China
随着数据执行保护 (如Linux下的PAX补丁[1]和Windows系统中的DEP[2]) 的广泛采纳，传统的代码注入和代码复用技术如return-to-libc，攻击能力受到严重限制.Shacham等人[3~5]提出了ROP (return oriented programming)，它复用应用程序二进制代码段及其依赖的库函数中的短指令序列 (gadget)，该技术无需注入恶意代码，因此可有效绕过数据执行保护，执行满足图灵完备性的任意计算.由于ROP shellcode构造简单、攻击性强，严重威胁到系统安全，尽管主流操作系统普遍部署了地址空间布局随机化技术 (address space layout randomization，ASLR)[6]，增加了ROP攻击的难度，但它依然可通过暴力破解或内存泄露成功绕过，大量与ROP相关的CVE仍不断涌现，例如最近爆出的glibc (CVE-2015-7547)[7]、pdfium (CVE-2015-6787)[8]、Wireshark (CVE-2015-8736)[9].因此迫切需要研究低开销、高精确度的ROP检测和防御机制.
目前各种ROP防护策略已不断被提出[10]，现有的主流防御技术大多基于硬件寄存器，如kBouncer[11]和ROPecker[12]利用LBR (last branch record) 寄存器，但是攻击者可利用long gadgets和call-preceded gadgets绕过kBouncer和ROPecker[13~15]；HDROP[16]和HadROP[17]利用硬件性能计数器HPCs，但HDROP选取的性能事件较少，误报率较高，HadROP触发检查时间不合理，漏报率较高.因此本文基于ROP攻击影响程序运行过程中的性能事件值，并参考动态插桩的缓冲区溢出漏洞检测技术[18]，提出了利用硬件性能计数器的函数级插桩检测方法，设计和实现了基于性能事件的ROP检测系统HBROP (HPC-Based approach to detect ROP attack)，HBROP首先离线分析应用程序正常执行的性能事件的值，然后以内核模块的方式监控程序执行，定期收集对应性能事件的值，在敏感系统调用执行之前，触发中断，和离线分析阶段的数据对比，判断是否存在异常，如果存在则警告用户存在攻击或直接终止程序执行.
本文的主要贡献如下：
1) 采用函数级插桩，对比同一函数的正常值和异常值，检测ROP精确度高；
2) 从理论角度筛选出ROP shellcode影响最大的几个性能事件，并通过实验论证；
3) 利用HPC寄存器是处理器内置的，因此具有对被测试程序干扰小、数据收集速度快、系统开销小等优点.
1 背景知识 1.1 ROP (Return Oriented Programming)ROP是一种细粒度的代码复用攻击，可有效绕过数据执行保护.攻击者首先遍历应用程序二进制代码段及其依赖的库函数，搜索机器语言序列 (称为gadgets)，这些gadgets通常完成诸如读写内存、算术逻辑运算、程序跳转、函数调用等操作，然后控制堆栈，在其中合理布局gadgets地址，使应用程序以某种顺序执行gadgets，最终实现任意 (图灵完备) 的恶意计算.通常gadgets以ret指令结尾，但由于此类ROP有以下两个较明显的特征：1) call、ret数量不匹配；2) 频繁执行连续的ret指令序列，因此很容易被检测到.为了克服这一缺陷，文献[19]提出了ROP变种攻击技术JOP (jump oriented programming)，使用和ret功能类似的pop-jmp指令结尾的gadgets.但无论是ROP gadgets还是JOP gadgets都分布在整个进程空间，不满足时间和空间局部性，对缓存未命中、分支预测不命中等性能事件影响较大.
1.2 基于硬件的ROP检测机制及进展攻防对抗通常都是此消彼长的，基于源码的检测方法需要原始代码，通用性不强[20].基于硬件的检测方法，由于性能开销低逐渐成为研究热点. kBouncer[11]、ROPecker[12]就是其中的典型，他们都利用硬件计数器LBR程序运行时进行检测，对用户完全透明.kBouncer利用CPU上的专用寄存器LBR记录ret指令的返回地址，检查是否频繁执行ret指令，同时判断每个ret返回地址是否在call指令之后.ROPecker也利用LBR记录分支信息，不同的是，ROPecker离线收集所有可能的gadgets，存入IG数据库中，然后在线监控程序执行，若执行代码段超出滑动窗口，检查LBR记录项中的分支指令是否位于IG数据库，即是否为gadgets，以此统计gadgets数量，如果gadgets值超过某一阈值，则警告存在ROP攻击.攻击者都能通过long gadgets和call-preceded gadgets绕过kBouncer和ROPecker[13~15].
陆续有研究者提出利用硬件性能计数器的防御方案.2014年石文昌等人设计了HDROP[16]，在程序执行过程中利用性能计数器 (hardware performance counters，HPCs) 定期收集未预测成功的ret指令数 (BR_RET_MISSP_EXEC，简称missp_num) 和ret总指令数 (BR_RET_EXEC，简称exec_num), 若不满足a* exec_num < missp_num < a* exec_num + b + c，则警告用户存在ROP攻击.2015年Pfaff等[17]提出的ROP防御思想HadROP与HDROP有异曲同工之妙，基于ROP shellcode执行过程中，编译器会产生更多的micro-architectual事件，利用HPCs收集事件的值，通过机器学习的方法离线分析micro-architectural值的正常范围，程序执行过程中，HadROP的内核组件定时触发中断，收集每个事件的值，并检查其是否在正常范围内.
但HDROP和HadROP都存在一定缺陷，HDROP只选取了BR_RET_MISSP_EXE和BR_RET_EXEC两个事件值，检测算法也过于简单，误报率较高；且HDROP选取的特征都和ret有关，只能检测ROP，不能检测JOP.HadROP由CPU定时触发中断收集event值，如果中断时间设置不合理，攻击者容易绕过，文献[17]中并没有解释如何选取中断时间.本文提出的基于硬件性能事件的函数级插桩检测方法能够弥补上述不足，并能平衡开销和精确度.
2 本文的检测方法本文是基于ROP攻击会影响缓存命中率、分支预测不命中等性能事件值的原理设计HBROP的，因此需要预先收集和处理程序正常运行时性能事件值，然后动态监控程序，以正常值为基准，比较运行过程中对应值，判断是否存在异常.所以HBROP分为离线预处理和动态监控两个阶段.
在离线预处理阶段，对应用程序X，构造各种不同种类的输入，使其尽可能覆盖所有可能的执行流，收集所有函数中的性能事件值，避免在线监控阶段，收集到的性能事件值没有参照值.最终将每个函数正常的性能事件值存放在benign HPCs database中，作为在线监控阶段的参照值.
在动态监控阶段，同样以函数为单位收集精心挑选的性能事件值，在调用敏感系统函数之前，HBROP中断程序，使用聚类算法以函数为单位分析性能事件值和benign HPCs数据库中对应值，判断是否存在异常，如果不存在，继续执行程序，否则警告用户或直接终止程序执行.
CPU提供了100余个性能事件，挑选合适的性能事件，准确区分ROP和JOP，是本文首先应该考虑的问题.
2.1 性能事件为了了解CPU利用率，降低应用程序性能损耗，现代高性能处理器内置了硬件性能计数器 (hardware performance counters，HPCs)，监控应用程序执行，统计存储、浮点运算、流水线事件、缓存命中率等与性能密切相关的事件.不同类型的处理器，提供的HPC个数不同，命名规则也不相同，但统计的原生事件 (native event) 功能类似 (周期和指令数，分支预测不命中).我们发现由The University of Tennessee创新计算实验室开发的开源工具PAPI (performance application programming interface)[21]，将不同处理器中存在功能共性的原生事件抽象成了PAPI接口专用的预设事件 (preset event) 并统一命名，实现了平台无关性.因此为了提高通用性，本文调用PAPI提供的标准接口low/high api统计程序某一段使用的时钟周期数，执行指令数，分支预测失败数，L1/L2/L3缓存访问/未命中数等.使用PAPI具有以下优点：1) 平台无关性，2) 允许同时收集多个预设事件，克服了在任意时刻一个计数器只能检测一个原生事件这一缺陷.
处理器提供了一百余种性能事件，但ROP攻击不会影响所有性能事件，且分析所有事件的值，性能开销大，因此需挑选合适的事件.ROP攻击的影响主要表现在以下3个方面：
1) 对分支指令的影响.实施ROP攻击，首先通过缓冲区溢出劫持控制流，因此会覆盖程序原有的局部变量，若此变量为分支判定条件，可能使程序偏离原有执行轨迹，影响未执行的分支指令数 (PAPI_BR_NTK) 和执行过的分支指令数 (PAPI_BR_TKN).ROP shellcode是由连续的以ret、jmp指令结尾的短指令序列组成，因此，完成恶意计算之前，条件分支指令数 (PAPI_BR_CN) 和分支指令数 (PAPI_BR_INS) 会明显增加.
2) 影响指令预测数.为了提高CPU的运算速度，现代微处理器引进了分支预测和推测执行[22].由于ROP gadgets分散在整个进程空间，不具备时间和空间局部性，分支预测成功率大大降低.因此本文选取条件分支指令预测不命中数 (PAPI_BR_MSP)，并结合条件分支指令成功预测数 (PAPI_BR_PRC) 检测是否存在ROP.
3) 影响cache命中率.CPU高速缓冲是用于减少处理器访问内存所需平均时间的部件[22]，利用了应用程序时间和空间局部性原理，因此遭受ROP攻击的应用程序，缓存命中率存在异常.本系统收集一级cache指令未命中数 (PAPI_L1_ICM) 和一级cache总的 (指令和数据) 未命中数 (PAPI_L1_ICM) 的值.
后续的对比试验，也证明ROP攻击对上述性能事件影响较大，而其他事件变化较小，甚至没有变化.
表 1是根据ROP攻击对程序的影响，挑选出的几个预设事件.
| 预设事件 | 原生事件 | 描述 |
| PAPI_BR_CN | BR_INST_RETIRED:CONDITIONAL | 条件分支指令数 |
| PAPI_BR_INS | BR_INST_RETIRED:ALL_BRANCHES | 分支指令数 |
| PAPI_BR_NTK | BR_INST_RETIRED:NOT_TAKEN | 未执行的分支指令数 |
| PAPI_BR_TKN | BR_INST_RETIRED:NOT_TAKEN | 执行过的分支指令数 |
| PAPI_BR_MSP | BR_MISP_RETIRED:ALL_BRANCHES | 条件分支指令误预测数 |
| PAPI_BR_PRC | BR_INST_RETIRED:ALL_BRANCHES BR_MISP_RETIRED:ALL_BRANCHES |
条件分支指令成功预测数 |
| PAPI_L1_ICM | ICACHE:MISSES | 一级指令cache未命中数 |
| PAPI_L1_TCM | ICACHE:MISSES L1D:REPLACEMENT |
一级总cache未命中数 |
HBROP是根据程序运行过程中性能事件的异常来检测ROP攻击的，因此收集性能事件粒度、何时触发检查机制、选取何种评判算法是设计HBROP方法时面临的三个问题.
2.2.1 收集性能事件的插桩粒度如果以整个函数为数据收集单元 (data collecting unit，DCU)，性能开销几乎为0，但ROP shellcode只有一百多条指令，对硬性计数器的影响集中在恶意计算完成之前，因此以整个应用程序为DCU，精确度低.若每执行一条指令，收集一次性能计数器的值，尽管精确度高，却大大增加了执行时间，加上后续处理和对比数据，性能代价太大.
我们发现：1) 一个函数的子函数一般不超过100个[15]，也就是说分支指令数在100以内，但为了绕过数据执行保护，完成复杂恶意计算，ROP gadgets相对较多，而每个gadgets以ret或jmp指令结尾，因此函数单位，可以准确区分程序正常执行时的性能事件值和ROP攻击收集的性能事件.2) 程序在运行过程中，一个函数的代码段和数据段集中存在放内存中，缓存命中率高，分支预测不命中数低，但ROP gadgets不满足局部性原理，上述两个性能事件与正常执行时相比变化明显.3) HBROP在收集性能事件的同时，记录函数的名字，在后续运行监控过程中，可以检测同一函数的性能事件是否存在异常，若以n条指令划分DCU，则不能比较同一个DCU下对应性能事件值，不同DCU功能、指令种类相差较大，则分支指令条数、命中率等性能事件值差异越大，而同一函数的性能事件变化小，所以以函数为DCU精确度高.因此为了平衡性能开销和精确度，本文选取以函数为单位进行插桩，在3.3.2节实验证明，函数插桩精确度高，性能开销相对较低.
2.2.2 触发检查时间HDROP事先计算表达式a×exec_num < missp_num < a×exec_num + b + c中a, b的值，一旦确定，程序运行过程中不会改变，然后监控程序执行，收集性能事件的同时判断其值是否满足表达式.此方法每次调用函数时，都会执行中断程序，检查是否存在ROP攻击，性能损耗较大.HadROP是以某个时间间隔定时触发中断，然后检查收集到的性能事件值，如果时间间隔设置不合理，可能在两个中断之间执行ROP攻击，绕过HadROP的检测.因此何时触发检查影响系统漏报和误报率.
我们发现不管实施何种攻击，最终都需要通过操作系统提供的访问文件、执行命令、网络通信等功能才能达到获取敏感信息、控制计算机系统的目的.如通过系统调用execve执行/bin/sh，新建一个shell，执行任意命令；然后调用setreuid函数获得root权限 (即本地提权).因此HBROP预先定义敏感系统函数集，然后以内核模块的方式监控程序执行，在调用敏感系统函数之前，中断程序，分析收集到的性能计数器的值.
2.2.3 评判算法前面已介绍，当存在ROP攻击时，硬件性能事件存在异常，如何辨别异常，在设计HBROP时至关重要.我们发现，无论输入何种数据，正常执行程序时，同一函数同一性能事件值相近，而存在ROP攻击时，性能事件值相差较大，和正常值不在同一范围内.因此可使用聚类算法分析数据，聚类 (clustering) 是按照“最大化簇内相似性，最小化簇间相似性”的原则，将数据集划分为若干组 (class) 或簇 (cluster) 的过程，同一簇内的数据对象集中在某一范围内，而与其他簇中的对象相异.
当前有多种聚类算法，层次法、划分法、密度算法等，本文只需要将收集到的值划分为正常值和受ROP攻击影响值，使用划分聚类算法就能快速有效低区分异常值和正常值.目前主流的划分算法有k-means，k-medoids，相对于k-means而言，k-medoids使用最接近聚类中心的对象作为类中心，增强了算法的鲁棒性，且聚类结果不易受离群点的影响.因此我们选取k-medoids算法处理数据.
3 实验与评估本文在有如下配置Intel i5-2350M CPU、4 GB RAM、128GB SSD、Ubuntu 15.04的机器上实现HBROP原型系统，并对glibc (CVE-2015-7547)[22]、noip[23]等实际漏洞进行测试.依据第二章的分析，设计出的HBROP系统架构如图 1.
|
| 图 1 HBROP架构 Figure 1 HBROP architecture |
依据2.2.1小节分析，本文以函数最为基本性能收集单元DCU在每个函数前进行插桩，用于读取函数名和硬件性能事件的值，两个相邻函数读取到的值相减，作为前一个函数性能事件的值.数据收集模型图如图 2.
|
| 图 2 数据收集模型 Figure 2 Data collection model |
本文采用Intel Pin插桩工具进行函数级插桩，每个call函数为插桩点 (instrument point，IP)，插入分析函数 (analysis functions) 收集性能事件的值，两个call函数之间统计值之差即为上一段代码对应的性能时间值.如在IP1读取的PAPI_BR_CN值为value1，IP2：value2，则fun1函数执行过程中，PAPI_BR_CN的值为value2-value1.实验过程中收集到的部分结果如表 2.
| 性能事件 | brk | memcpy4 | _libc_init_first |
| PAPI_BR_CN | 297 | 70 | 284 |
| PAPI_BR_INS | 422 | 660 | 412 |
| PAPI_BR_NTK | 178 | 286 | 181 |
| PAPI_BR_TKN | 244 | 374 | 231 |
| PAPI_BR_MSP | 49 | 69 | 62 |
| PAPI_BR_PRC | 383 | 601 | 364 |
| PAPI_L1_ICM | 151 | 101 | 121 |
| PAPI_L1_TCM | 116 | 178 | 186 |
表 2第一行为函数名，接下来的每一行分别表示程序运行过程中收集到的PAPI_BR_CN、PAPI_BR_INS、PAPI_BR_NTK、PAPI_BR_TKN、PAPI_BR_MSP、PAPI_BR_PRC、PAPI_L1_ICM、PAPI_L1_TCM性能事件的值.由表 2可知，同一函数不同性能事件值相差较大，不同函数同一性能事件值差别也很大，因此为了增加精确度，需分别比较同一函数各个性能事件是否存在异常.
3.2 聚类分析本文选取k-medoids算法聚类分析数据，该算法的处理流程大致为：
第一步随机选取k个对象作为初始中心点代表该类，
第二步遍历非中心点对象i，
第三步计算以i为中心点的总代价s，若s < 0，则选取i为新的中心点，
第四步重复第二、第三步遍历完所有的非中心点，直到k个中心点不再发生变化.
部分聚类代码如下：
最终处理后的部分聚类结果如图 3所示.
|
| 图 3 事件处理结果 Figure 3 Event processing results |
前100个蓝色点是执行到某一函数收集到的PAPI_BR_INS、PAPI_BR_NTK、PAPI_BR_TKN、PAPI_L1_TCM的值，其值都在某个值上下徘徊；红色的×表示受ROP攻击时，收集到的值，和正常值差异明显，划分到另一个簇.
|
现代处理器中供用户读取的性能事件有上百个，本文根据ROP的特征挑选了8个性能事件，为了验证ROP攻击确实对上述性能事件影响较大，而对其他值影响小，本文做了如下对比试验，离线处理glibc、noip数据时，收集Ubuntu 15.04能支持的所有性能事件的值，然后进行ROP攻击，分析ROP攻击对这些性能事件的影响.实验结果如图 4.
|
| 图 4 ROP攻击对不同性能事件影响对比 Figure 4 Comparison of ROP attacks on different performance events |
图 4中亮蓝色是执行ROP攻击收集到的部分性能事件值，其他都是正常值，以盒须图的形式显示.上4个是文中选取的其中4个性能事件，下面4个是其他无关的事件.由图 4可知，当遭受ROP时，本文选取的性能事件影响较大，严重偏离正常值，而随机选取的其他四个无关性能事件值几乎不受影响，在中位值附近.因此从实验角度论证了文中选取的性能事件能够精确辨别ROP攻击.
3.3.2 插桩单元2.2小节分析了不同的插桩粒度会影响精确度和性能开销，HBROP以函数为一个性能收集单元，分析阶段只需比较对应函数的性能事件的值.为了验证以函数为单位能平衡精确度和性能开销，本文分别选取256、512、1 024、2 048条指令划分DCU，检测相同数量的ROP攻击，统计各自的精确度和对程序运行时间的影响.结果如图 5所示.
|
| 图 5 精确度和性能开销 Figure 5 Accuracy and performance overhead |
ROP检测系统最好精确度高、开销低，从图 5可知，尽管以函数为单位或每64、128条指令为单位收集数据，精确度都比较高，但以函数为单位对应用程序影响最小.由此说明，本文选取的以函数为DCU能够平衡性能开销和精确度.
3.3.3 性能评估HBROP利用的是系统内置的寄存器，读取数据时间忽略不计，消耗主要集中在拦截敏感系统调用，处理数据和聚类分析数据.本文使用SPEC CPU 2006[24]性能测试工具计算性能损耗，在部署HBROP前后分别运行测试组件.为了充分了解HBROP的性能开销，本文除了对glibc，noip等实际漏洞进行评估外，还统计了在输入常规数据的情况下，HBROP对gedit、firefox、cat、ls等常用软件的影响.如表 2所示，HBROP平均开销在5%左右，最坏情况约为8%.和现有防御机制的性能损耗：HDROP 16%[15]、HadROP 5%[16]、ROPecker 7%[11]、kBouncer 1%[10]相比，HBROP的性能损耗在可接受范围内.HBROP和HDROP都基于性能计数器，但为了提高精确度，HBROP采用了机器学习的方法，与HDROP相比，增加了性能开销；kBouncer从LBR寄存器中获取的分支记录可以检测ROP攻击，但由于HBROP的检测原理不同，需获取每个函数的性能时间值，使用了函数级插桩的方法，造成了一定的性能损耗.
| 类别 | 软件 | 性能损耗/% |
| 漏洞软件 | glibc | 4.98 |
| noip | 4.65 | |
| 常用软件 | gedit | 7.32 |
| firefox | 4.95 | |
| python | 8.06 | |
| /bin | cat | 4.88 |
| ls | 4.53 | |
| mv | 4.62 | |
| /usr/bin | cal | 4.84 |
| g++ | 7.67 | |
| env | 5.34 |
本文基于ROP攻击会影响程序运行过程中分支指令执行条数，缓存命中率，分支预测不命中等性能事件的现象，提出了利用硬件性能计数器的ROP检测方法HBROP，以函数为单位收集数据，使用k-medoids算法聚类分析同一函数相同性能事件是否存在异常，能够准确检测ROP和JOP攻击.通过理论分析和实验论证，本文选取的性能事件能准确判断ROP攻击，且性能开销较低.在今后的研究过程中，将结合其他硬件寄存器如LBR、BTS (Bit Test and Set)，进一步降低HBROP的误报和漏报率.
| [1] | The PaX Team. Homepage of The PaX Team[DB/OL]. [2016-01-04].https://pax.grsecurity.net/. |
| [2] | VAN DE VEN A. New security enhancements in red hat enterprise linux v. 3, update 3[DB/OL]. [2016-01-05]. http://www.redhat.com/f/pdf/rhel/WHP 0006US_Execshield.pdf. |
| [3] | SHACHAM H. The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86)[C]//Proceedings of the 14th ACM Conference on Computer and Communications Security. New York: ACM, 2007: 552-561. |
| [4] | BUCHANAN E, ROEMER R, SHACHAM H, et al. When good instructions go bad: Generalizing return-oriented programming to RISC[C]//Proceedings of the 15th ACM conference on Computer and communications security. New York: ACM, 2008: 27-38. |
| [5] | CHECKOWAY S, DAVI L, DMITRIENKO A, et al. Return-oriented programming without returns[C]// Proceedings of the 17th ACM conference on Computer and communications security. New York: ACM, 2010: 559-572. |
| [6] | The PaX Team. Address space layout randomization[DB/OL]. [2016-02-12]. https://pax.grsecurity.net/docs/aslr.txt. |
| [7] | Google Security Research. glibc-getaddrinfo Stack-Based Buffer Overflow[DB/OL]. [2016-03-04]. https://www.exploit-db.com/exploits/39454/. |
| [8] | Google Security Research. pdfium CPDF_Function::Call -Stack-Based Buffer Overflow[DB/OL]. [2016-03-04]. https://www.exploit-db.com/exploits/39165/. |
| [9] | Google Security Research. Wireshark -file_read (wtap_read_bytes_or_eof/mp2t_find_next_pcr) Stack-Based Buffer Overflow[DB/OL]. [2016-03-04]. https://www.exploit-db.com/exploits/38997/. |
| [10] | FOLLNER A, BODDEN E. ROPocop -Dynamic mitigation of code-reuse attacks[J]. Journal of Information Security & Applications, 2015(29) : 16–26. |
| [11] | PAPPAS V, POLYCHRONAKIS M, KEROMYTIS A D. Transparent ROP Exploit Mitigation Using Indirect Branch Tracing[C]// 22nd USENIX Security Symposium. Berkeley: USENIX, 2013: 447-462. |
| [12] | CHENG Y, ZHOU Z, MIAO Y, et al. ROPecker: A generic and practical approach for defending against ROP attack[J]. Proceedings of the 21th Annual Network and Distributed System Security Symposium, 2014(2) : 1–14. |
| [13] | CARLINI N, WAGNER D. ROP is still dangerous: Breaking modern defenses[C]// 23rd USENIX Security Symposium (USENIX Security 14). Berkeley: USENIX, 2014: 385-399. |
| [14] | DAVI L, SADEGHI A R, LEHMANN D, et al. Stitching the gadgets: On the ineffectiveness of coarse-grained control-flow integrity protection[C]// 23rd USENIX Security Symposium (USENIX Security 14). Berkeley: USENIX, 2014: 401-416. |
| [15] | GÖKTAS E, ATHANASOPOULOS E, POLYCHRONAKIS M, et al. Size does matter: Why using gadget-chain length to prevent code-reuse attacks is hard[C]// 23rd USENIX Security Symposium (USENIX Security 14). Berkeley: USENIX, 2014: 417-432. |
| [16] | ZHOU H W, WU X, SHI W C, et al. HDROP: Detecting ROP attacks using performance monitoring counters[C]//International Conference on Information Security Practice and Experience. Berlin: Springer, 2014: 172-186. |
| [17] | PFAFF D, HACK S, HAMMER C. Learning how to prevent return-oriented programming efficiently[C]//International Symposium on Engineering Secure Software and Systems. Berlin: Springer, 2015: 68-85. |
| [18] | 刘露平, 方勇, 刘亮, 等. 基于动态插桩的缓冲区溢出漏洞检测技术研究[J]. 信息安全与通信保密, 2015(4) : 80–82. LIU L P, FANG Y, LIU L, et al. Buffer overflow vulnerability detection technology based on dynamic instrumentation[J]. Information Security and Communications Privacy, 2015(4) : 80–82(Ch). |
| [19] | BLETSCH T, JIANG X, FREEH V W, et al. Jump-oriented programming: A new class of code-reuse attack[C]//Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security. New York: ACM, 2011: 30-40. |
| [20] | 尹茗, 张功萱. 基于源码分析的缓冲区溢出漏洞检测方法[J]. 江苏大学学报:自然科学版, 2016, 37(4) : 450–455. YIN M, ZHANG G X. Buffer overflow detection method based on source code analysis[J]. Journal of Jiangsu University: Natural Science Edition, 2016, 37(4) : 450–455(Ch). |
| [21] | ICL of University of Tennessee. PAPI Programmer's Reference [DB/OL]. [2016-01-04].http://icl.cs.utk.edu/papi. |
| [22] | Google Security Research. Glibc-getaddrinfo Stack-Based Buffer Overflow[DB/OL]. [2016-03-04]. https://www.exploit-db.com/exploits/39454. |
| [23] | Alberto Ortega. No-IP Dynamic Update Client (DUC) 2.1.9-Local IP Address Stack Overflow[DB/OL]. [2016-03-04]. https://www.exploit-db.com/exploits/25411. |
| [24] | Standard Performance Evaluation Corporation. Standard Performance Evaluation Corporation[DB/OL]. [2016-03-04].http://www.spec.org. |