张正(1993-), 男, 博士生, 主要研究领域为系统安全
薛静锋(1975-), 男, 博士, 教授, 博士生导师, 主要研究领域为网络安全, 数据安全, 软件安全, 软件测试
张静慈(1991-), 女, 博士生, 主要研究领域为网络安全
陈田(1995-), 男, 博士生, 主要研究领域为系统安全
谭毓安(1972-), 男, 博士, 教授, 博士生导师, CCF高级会员, 主要研究领域为Android安全, 深度学习及对抗, 物联网与嵌入式系统, 数据存储安全
李元章(1978-), 男, 博士, 副教授, CCF专业会员, 主要研究领域为信息安全, 嵌入式技术
张全新(1974-), 男, 博士, 副教授, 主要研究领域为深度学习及其对抗技术, 计算机视觉安全, 信息安全
控制流劫持攻击利用程序内存漏洞获取程序的控制权, 进而控制程序执行恶意代码, 对系统安全造成极大的威胁. 为了应对控制流劫持攻击, 研究人员提出了一系列的防御手段. 控制流完整性是一种运行时防御方法, 通过阻止进程控制流的非法转移, 来确保控制流始终处于程序要求的范围之内. 近年来, 越来越多的研究致力于解决控制流完整性的相关问题, 例如提出新的控制流完整性方案、新的控制流完整性方案评估方法等. 首先阐述了控制流完整性的基本原理, 然后对现有控制流完整性方案进行了分类, 并分别进行了分析, 同时介绍了现有针对控制流完整性方案的评估方法与评价指标. 最后, 对控制流完整性的未来工作进行了展望, 以期对未来的控制流完整性研究提供参考.
Control-flow hijacking attacks exploit memory corruption vulnerabilities to grab control of the program, and then hijack the program to execute malicious code, which brings a great threat to system security. In order to prevent control-flow hijacking attacks, researchers have presented a series of defense methods. Control-flow integrity is a runtime defense method that prevents illegal transfer of process control-flow to ensure that control-flow is always within the range required by the program. In recent years, more and more research works are devoted to solving related problems of control-flow integrity, such as presenting new control-flow integrity schemes, new control-flow integrity scheme evaluation methods, etc. This study explains the basic principles of control flow integrity, and then classifies existing control flow integrity schemes. The existing evaluation methods and evaluation indicators of the control-flow integrity scheme are introduced at the same time. Finally, the thoughts on potential future work on control-flow integrity is summarized, which, hopefully, will provide an outlook of the research direction in the future.
随着计算机技术的不断发展, 各类计算机软件的出现给人们带来极大的便利. 然而由于计算机体系和编程语言存在的固有局限性, 计算机软件不可避免地存在一些安全漏洞. C/C++因其较高的执行效率, 成为很多底层库、大型软件实现的首选语言, 其内存管理机制需要开发者自行申请和释放内存, 这为设计和实现高效程序提供了极大自由度, 但同时也为内存安全埋下隐患. 输入数据超过缓冲区可容纳的最大数据量并溢出到临近存储区域便会引发缓冲区溢出漏洞. 缓冲区溢出漏洞是当今危害最为广泛的安全漏洞之一, 且难以彻底消除[
为了抵御控制流劫持攻击, 一系列应对策略相继被提出, 根据防御引入时间可以分为运行前的静态防御技术和运行时的动态防御技术[
2005年, Abadi等人提出了控制流完整性(control flow integrity, CFI)[
本文对CFI方法进行了全面的调查和论述, 第1节阐述了CFI的基本原理, 从技术原理的角度将现有的CFI方法分类为上下文无关的CFI和上下文敏感的CFI; 第2节介绍了本文的文献调研方法和调研结果, 并对不同方法进行了归纳总结; 第3节将上下文无关的CFI分类为基于源码的CFI、基于二进制的CFI和硬件支持的CFI并分别阐述了其原理机制; 第4节介绍了上下文敏感的CFI; 第5节阐述了CFI的评价方法, 并根据评估角度对现有的CFI评估研究进行对比、讨论和分析; 最后, 第6节对全文进行了总结与展望.
CFI对控制流的保护主要分为两个阶段, 首先是在运行前对程序进行源码分析或二进制分析, 获得程序的控制流图(control flow graph, CFG), 然后在程序运行时监测程序控制流是否始终处于CFG中, 来判断程序是否遭受了攻击. CFG是一个由基本块和有向边组成的图, 其中每一个基本块代表一段在中间不包含控制流跳转指令和其他控制流跳转指令的目标的连续代码, 每一条有向边则代表程序控制流的一次转移. CFI机制使用的CFG为过程间CFG, 包含了函数间的调用边(call edge)和返回边(return edge).
程序控制流图及CFI机制的工作原理图
控制流的转移以跳转指令为基础. 程序通过跳转指令进入不同分支执行, 而保证跳转指令的目标分支地址始终合法即维护了进程控制流的完整性. 以x86平台为例, 跳转指令包括jmp指令、call指令和ret指令. 其中jmp指令和call指令将程序控制流转移到一个新的位置, 称为前向转移; ret指令将程序的控制流返回到先前的位置, 称为后向转移. 跳转指令根据寻址方式的差异, 可以分为直接和间接两种形式. 其中直接跳转指令根据给定的目标绝对地址或相对偏移量完成跳转, 且地址在运行时无法修改. 因此在DEP技术有效的前提下, 只要保证代码的完整性, 直接跳转可以被视为安全指令; 间接跳转指令的目标地址由寄存器给出, 且在程序执行时动态决定, 因此间接跳转指令的目标地址有被攻击者恶意篡改的风险. 因此CFI的目标在于确保进程间接跳转指令的目标地址始终合法, 对前向间接转移的保护称为前向边沿保护(forward-edge protect), 对后向间接转移的保护称为后向边沿保护(backward-edge protect).
研究人员在原始CFI思想的基础上, 提出了一系列应用于不同场景的CFI方案. 现有工业界和学术界提出的CFI方案囊括了基于源代码的实现、基于二进制可执行文件的实现、编译器层面、内核层面的实现以及利用CPU硬件特性的实现等诸多层面, 其适用范围、防护安全性以及运行开销均有不同. 此外, 为了抵御愈来愈强大的控制流劫持攻击, 研究人员开始考虑将进程执行状态的上下文语义加入到CFI方案中, 相对于此前无状态的CFI方案, 进一步提高了其防御能力. 尽管CFI方案的形式多变, 其目的始终是为了获得更好的防御性能和更低的性能开销.
如
CFI机制的分类
本节介绍了本文的文献调研方法和调研结果. 目前Burow等人[
为了对本文所研究的问题进行系统的梳理和分析, 首先以“Control Flow Integrity”“Control-Flow Attacks”“Control Flow Hijacking”等设为主要搜索关键词, 在国内外重要的学术搜索引擎(例如谷歌学术搜索、CNKI等)中检索相关论文; 然后, 筛选出与综述问题相关的论文; 接着, 通过已搜索到的论文获取更多的相关文献, 方法包括查阅论文的引用和被引用, 以及论文作者已发表论文的列表; 同时参考已有综述性文献的调研情况, 确定了最终的文献列表. 其中包括提出CFI方案的论文60篇、相关评测基准套件或方法17个、其他与综述研究问题直接相关的论文30篇.
论文数量增长趋势
CFI方案总结
文献 | 年份 | 类别 | 技术特点 |
HyperSafe[ |
2010 | 基于源码 | 内存页面锁定+间接跳转目标白名单 |
MIP[ |
2013 | 基于源码 | 代码分块+边界检查 |
MCFI[ |
2014 | 基于源码 | 代码分块+唯一ID匹配 |
Forward-CFI[ |
2014 | 基于源码 | 间接跳转目标白名单, 只保护前向边沿 |
KCoFI[ |
2014 | 基于源码 | 唯一ID匹配结合影子堆栈保护返回地址 |
RockJIT[ |
2014 | 基于源码 | 代码分块+唯一ID匹配 |
JITScope[ |
2015 | 基于源码 | 唯一ID匹配结合影子堆栈保护返回地址 |
πCFI[ |
2015 | 基于源码 | 将特定输入对应的CFG边沿逐一加入全局CFG中 |
Fine-CFI[ |
2018 | 基于源码 | 函数指针分析 |
IBV-CFI[ |
2020 | 基于源码 | 为所有间接转移指令生成独立的位向量, 并在位向量中存储每个间接转移指令的有效目标集 |
MoCFI[ |
2012 | 基于二进制程序 | 间接跳转目标白名单+影子堆栈 |
CCFIR[ |
2013 | 基于二进制程序 | 使用Springboard段验证间接跳转目标并转发 |
BinCFI[ |
2013 | 基于二进制程序 | 间接跳转目标白名单 |
BinCC[ |
2015 | 基于二进制程序 | 代码分块+边界检查 |
O-CFI[ |
2015 | 基于二进制程序 | 细粒度的代码随机化和粗粒度的控制流保护相结合 |
Lockdown[ |
2015 | 基于二进制程序 | 代码分块+影子堆栈 |
TypeArmor[ |
2016 | 基于二进制程序 | 构造控制流不变式, 只保护前向边沿 |
τCFI[ |
2018 | 基于二进制程序 | 函数参数类型和参数数量匹配验证 |
RECFISH[ |
2019 | 基于二进制程序 | 标签匹配保护前向边沿+影子堆栈保护返回地址 |
CFIMon[ |
2012 | 硬件支持 | BTS辅助收集进程的间接跳转目标地址 |
kBouncer[ |
2013 | 硬件支持 | LBR辅助收集进程的间接跳转目标地址 |
ROPecker[ |
2014 | 硬件支持 | LBR辅助收集间接跳转目标地址+滑动窗口机制 |
CFIGuard[ |
2015 | 硬件支持 | LBR和PMU组合实现控制流保护 |
PT-CFI[ |
2017 | 硬件支持 | PT辅助收集间接跳转目标地址并构成图结构+影子堆栈 |
µCFI[ |
2018 | 硬件支持 | PT辅助收集历史跳转目标, 确保间接跳转目标的唯一性 |
HCIC[ |
2018 | 硬件支持 | PUF辅助的线性加密/解密+加密的汉明距离匹配 |
PARTS[ |
2019 | 硬件支持 | 基于指针验证(PA)机制保护指针完整性 |
ABCFI[ |
2020 | 硬件支持 | 将标签构造为地址低位 |
SPECCFI[ |
2020 | 硬件支持 | 将CFI原则嵌入分支预测决策中 |
FastCFI[ |
2021 | 硬件支持 | 由FPGA实现并对ARM平台上运行程序进行监测 |
PathArmor[ |
2015 | 上下文敏感 | LBR辅助实现运行时执行路径监控 |
PITTYPAT[ |
2017 | 上下文敏感 | PT辅助重建执行路径, 实现运行时执行路径监控 |
OS-CFI[ |
2019 | 上下文敏感 | 将间接转移指令调用的代码指针的起源作为上下文 |
CFI-LB[ |
2019 | 上下文敏感 | 每个间接跳转分支具有自适应上下文敏感性 |
BCI-CFI[ |
2021 | 上下文敏感 | 将分支相关关系作为上下文信息 |
上下文无关的CFI不将进程执行的历史信息作为控制流转移合法性的参考依据, 只需保证控制流遵循预先确定的CFG的路径. 根据CFG获取方式的不同, 上下文无关的CFI可以进一步细分为基于源码的CFI、基于二进制程序的CFI和硬件支持的CFI. 基于源码的CFI可以通过被保护程序的源码确定每个间接转移指令的合法目标地址, 从而确定CFG中每个基本块之间是否存在可以转移的有向边, 因此可以构建精准的CFG; 不依赖源代码的CFI只使用二进制文件进行分析, 所得到的间接转移指令的目标地址集合与实际合法的目标地址集合存在差异, 这往往需要通过分析被保护程序所依赖的库、匹配函数调用时的参数数量[
Abadi等人提出了第一个上下文无关的CFI, 并给出了具体实施方案[
原始CFI的基本框架
基于源码的CFI利用程序源代码获取程序间接转移的详细信息, 从而构建精准的CFG. 此类方案在实际部署时, 或直接对源代码进行修改, 或将控制流保护逻辑集成在编译器或者操作系统内核中, 从而在程序运行前完成攻击检测与防御代码的安插. 相较于基于二进制程序的CFI方案, 可以执行更多的优化从而获得更好的性能.
Wang等人[
Niu等人[
Tice等人[
上述方法的关注重点以应用层的ROP攻击为主, 针对内核层级的攻击检测方法相对较少. Criswell等人[
Niu等人[
传统的CFI技术从程序中静态提取CFG, 并通过执行该CFG实现进程控制流的监测. 静态生成的CFG包括所有可能输入的所有边沿, 但对于具体的输入, CFG可能保护许多不必要的边沿. 针对这一问题, Niu等人[
此外一些研究提出针对IRM (inlined reference monitors)的控制流防护. IRM是一种底层安全机制, 该机制将监视器代码内联到汇编等低级代码, 以便在执行不安全操作之前对其进行检查. IRM可以依靠CFI或者SFI (software fault isolation)[
基于源代码的CFI多用于偏底层的控制流保护, 此类方法在内核层面实现相应接口的扩展并通过编译器为程序增加防御功能, 避免了开发人员手动添加防御代码, 为软件开发提供了便利. 然而此类方法在不提供源码或调试信息的应用程序中难以实现. 实际上, 商业软件往往以二进制可执行文件的形式发布, 用户在大多数情况下不能获取软件的源码, 这使得更多的CFI技术倾向于直接基于二进制文件或借助处理器硬件特性实现控制流保护.
许多CFI解决方案要求源码或调试信息才可正常使用, 在现实应用中往往难以得到满足, 这使得许多商业软件无法得到有效的保护. 因此, 基于二进制程序的CFI方案得到越来越多科研人员的关注. 基于二进制程序的CFI方案可以部署在没有源码的二进制程序中, 因此应用更加广泛. 此类方案通常会使用一些方法从二进制文件中生成控制流图, 设计CFI方案, 并使用二进制重写等技术将方案部署在原程序中. 由于无法使用源码来构建更加精准的控制流图, 所以获取更准确地间接跳转目标集合, 提高生成控制流图的精度成为研究人员的研究重点之一.
Zhang等人[
与CCFIR类似, BinCFI[
Wang等人[
O-CFI[
随着商用软件对版权保护及数据安全等需求的日益增加, 在二进制程序的基础上增加控制流防护措施变得尤为重要. 通过静态分析和二进制重写的方法实现CFI机制需要修改程序原本的二进制文件, 实际应用时面临较大的兼容性问题. 随着历史分支记录等机制的出现, 使用了类似硬件机制的CFI技术逐步摆脱了对二进制重写技术的依赖, 提高了防御的兼容性. 因此, 在仅有被保护软件二进制文件的情况下, 硬件支持的CFI逐步取代纯软件的实现方法.
为了进一步提高CFI的安全性和性能, 一些研究着眼于从硬件机制中寻求可用的支持. 目前商用处理器中基本都集成了性能监控单元(performance monitoring units, PMUs), 该功能最初用于监控应用程序的运行从而优化系统性能. 为了分析程序的控制流转移情况, 进一步提高PMUs的精确性, 大部分商用处理器还集成了分支追踪功能, 例如英特尔处理器的分支追踪存储(branch tracing store, BTS)和最近分支记录(last branch recording, LBR)等. 基于底层硬件功能进行程序控制流的监控, 检测控制流劫持攻击, 可以有效地降低CFI方案的运行开销.
Xia等人[
硬件支持的CFI机制的工作原理图
Pappas等人[
Gu等人[
一些方案将密码学应用于控制流的保护, 通过对间接转移的返回地址或函数指针进行加密, 阻止攻击者对其进行篡改. Qiu等人[
此外, 还有其他CFI方案也基于此类硬件机制得到较好的防御效果[
基于LBR、PT等硬件实现的CFI方案可以极大攻击检测的效率, 解决纯软件CFI方案高开销的问题, 但是此类防御需要相应硬件的支持, 没有对底层处理器架构进行更改. 不过随着ROP等控制流劫持攻击的流行, 包括Intel在内的处理器供应商开始逐步将安全原语集成到处理器设计中, 以有效应对特定的攻击. 例如最近加入到ARMv8-A架构的新指令指针验证(pointer authentication, PA)可以保护指针完整性, 这种直接将安全原语集成在底层处理器架构中的方式可以减小CFI方案对特定硬件的依赖, 将是硬件辅助的CFI方案的发展趋势.
随着控制流劫持攻击的迭代与发展, 粗粒度的CFI已经无法抵御最新的ROP攻击[
上下文无关的CFI往往只关注间接跳转目标地址的合法性, 而不关注跳转顺序的合法性, 粗粒度的CFI对间接转移目标地址类别的划分则更为宽松, 对同一目标集合中的目标地址的跳转顺序不做区分, 这便给了攻击者可乘之机. Göktas等人[
Carlini等人[
控制流弯曲举例[
作者通过实验成功攻击了具有较高平均间接目标减少量(average indirect target reduction, AIR)[
CCFI在提出时被认为不切实际而未引起人们关注, 因为其实现需要监控进程的执行历史路径或其他信息, 这会带来较大的运行开销. 随着计算机硬件的迭代发展, 商用处理器中集成了越来越多的进程执行信息获取机制, 例如Intel处理器的LBR和PT等, 这些硬件功能提供了有关直接和间接分支的丰富上下文信息, 从而使CCFI的实际应用成为了可能.
van de Veen等人[
PITTYPAT[
由于LBR、PT等硬件机制只能在内核模式下访问, 因此基于此类机制的CFI方案需要对内核进行更改, 这不仅增加了设计的复杂性, 也增加了性能开销. 针对这一问题, Khandaker等人[
由于一个间接转移指令对应的传入执行路径数量有限, PathArmor、PITTYPAT等路径敏感的CFI方案难以分解大规模的EC. 针对这一问题, Khandaker等人[
CCFI利用进程的上下文语义信息, 可以有效减小EC的大小, 理论上增强了CFI的防御能力, 而在实际应用中仍然面临一些问题. 安全性方面, 如何在有限的执行路径中找到合适的上下文, 从而有效地减小EC的尺寸, 是CCFI方案需要解决的关键问题. 性能方面, 现有的CCFI方案均使用了LBR、PT等硬件机制实现上下文信息的获取, 然而相较于上下文无关的CFI方案, CCFI的运行开销依然较大, 执行效率需要进一步提高. 从整个CFI技术发展的过程来看, 为了达到更好的安全性和性能, 未来CCFI技术的发展离不开底层处理器架构的支持.
为了对比和评价不同CFI机制的优劣, 研究人员也从不同角度提出了评价方法. 当前研究界主要关注CFI机制两个方面的指标: CFI机制的安全性指标和性能指标. 其中安全性指标衡量了CFI方案对控制流劫持攻击的防御性能, 而性能指标衡量了CFI方案的运行开销. 除此之外, 还有一些针对CFI方案的兼容性等其他方面的度量研究. 本节对现有CFI方案的评价研究进行了详细的介绍,
CFI评价方法总结
文献 | 发表年份 | 评价方法 | 评价角度 |
AIR[ |
2013 |
|
安全性 |
AIA[ |
2016 |
|
安全性 |
|
2017 |
|
安全性 |
|
2019 |
|
安全性 |
CONFIRM[ |
2019 | 由包含多种代码特性和编码习惯的CFI测试程序组成
|
适用性、兼容性 |
LLVM-CFI[ |
2019 | 使用静态源代码分析框架精确地建模CFI策略, 并使用统一的方法评估 | CFI方案的安全性等多角度的评估 |
CScan/CBench[ |
2020 | CFI实际边界测量工具CScan和CFI有效性测试套件CBench相结合进行评估 | 衡量CFI方案的实际安全与理论安全之间的差距 |
CFI是一种运行时防御手段, 对控制流的转移进行实时的监控, 其运行开销往往不可忽略. 性能较差的CFI方案会影响被保护程序的正常运行, 无法部署在实际应用中, 因此, CFI方案的性能受到研究人员的广泛关注. 当前科研人员通常使用SPEC CPU benchmark评估CFI方案的运行开销. SPEC CPU benchmark是标准性能评估机构SPEC推出的行业标准化的CPU测试基准套件, 专门用于评估CPU的性能, 被广泛应用于工业界和学术界. 为了保持基准数据的真实性、公平性和相关性, SPEC CPU从实际应用程序中提取基准, 而不是使用人工合成的方式制作. SPEC先后推出了SPEC CPU2000[
本文统计的CFI方案中, 超过2/3的方案使用SPEC CPU基准来评估性能开销. 其余方案没有使用SPEC CPU基准, 这是由于这些方案主要针对特定的应用场景, 包括用于虚拟机的控制流保护[
CFI机制的运行开销
方法 | 测试套件 | 平均开销(x86) | 最大开销(x86) | 平均开销(x86-64) | 最大开销(x86-64) |
Origin CFI[ |
SPEC CPU2000[ |
15 | 46 | - | - |
CCFIR[ |
SPEC CPU2000[ |
3.6 | 8.6 | - | - |
O-CFI[ |
SPEC CPU2000[ |
4.7 | 11 | - | - |
BinCFI[ |
SPEC CPU2006[ |
8.54 | 45 | - | - |
Lockdown[ |
SPEC CPU2006[ |
19.09 | 150 | - | - |
µCFI[ |
SPEC CPU2006[ |
- | - | 7.88 | 49.67 |
MCFI[ |
SPEC CPU2006[ |
5 | 10 | 5 | 12 |
ROPecker[ |
SPEC CPU2006[ |
2.6 | 15 | - | - |
πCFI[ |
SPEC CPU2006[ |
- | - | 3.2 | 11.4 |
PT-CFI[ |
SPEC CPU2006[ |
20 | 65 | - | - |
PathArmor[ |
SPEC CPU2006[ |
- | - | 8.5 | - |
TypeArmor[ |
SPEC CPU2006[ |
- | - | 2.4 | 9.8 |
PITTYPAT[ |
SPEC CPU2006[ |
- | - | 12.73 | 47.3 |
OS-CFI[ |
SPEC CPU2006[ |
7.6 | 15 | ||
CFI-LB[ |
SPEC CPU2006[ |
- | - | 4.8 | 8.4 |
BCI-CFI[ |
SPEC CPU2006[ |
19.67 | 31.2 | - | - |
ABCFI[ |
SPEC CPU2006[ |
- | - | 0.55 | 7 |
IBV-CFI[ |
SPEC CPU2017[ |
- | - | 1.42 | 6.64 |
kBouncer[ |
Wine[ |
- | - | 1 | 4 |
HCIC[ |
RIPE[ |
0.95 | 1.57 | 0.95 | 1.57 |
CFIGuard[ |
RIPE[ |
2.9 | 5.6 | - | - |
CFIMon[ |
Exim[ |
6.1 | 8.4 | - | - |
安全性是衡量CFI防御效果的最重要指标之一, 学界也针对CFI的安全性评价提出了多种度量方法, 包括评价指标、评估框架及评估套件. 然而, 由于各CFI方案的实现原理、应用场景差异较大, 到目前为止, 尚未形成统一的度量标准.
Zhang等人[
其中,
Ge等人[
其中,
Burow等人[
其中,
Khandaker等人[
其中,
不同CFI方案实现的底层硬件、操作系统以及基准选择的不同, 给统一评估CFI方案的安全性带来了较大的难度, 使用单一的评价指标难以全面评估CFI的防御性能. 针对这一问题, Muntean等人[
RIPE套件[
除了性能和安全性之外, 一些研究人员着眼于研究如何评价CFI方案的实际应用效果. Farkhani等人[
CFI机制部署到实际应用程序时, 会出现一些兼容性问题, 由于不兼容而无法得到CFI保护的应用程序面临极大的安全风险. Xu等人[
Li等人[
为了抵御控制流劫持攻击, 保护系统安全, 针对CFI的研究受到越来越多科研人员的关注. 本文提供了针对CFI的综述. 具体来说, 本文将现有CFI方法分为上下文无关的CFI和上下文敏感的CFI, 并从实现方案和评估方法两方面对该领域进行了详细全面的综述.
尽管目前已经有许多研究围绕CFI进行展开, 但目前针对该领域的研究还不够完善, 很多方面都具有较大的改进空间, 研究人员也正在积极地探索与改进. 在这里, 本章对仍然存在的挑战进行列举, 以期为未来的研究方向提供参考, 从而进一步提高对控制流劫持攻击的防御能力.
(1) CFI方案的安全性仍存在较大隐患. 粗粒度的CFI虽然运行开销较小, 但是已被证明难以抵御高级别的ROP攻击. CFB则提出了EC内可能存在的攻击行为, 证实了控制流可以在EC内部被攻击而不被检测到, 这使得具有较大EC规模的细粒度CFI亦无法幸免. 因此, 通过结合进程执行上下文有效减小最大EC规模的低开销CCFI, 是一个可能的探索方向.
(2) 尽管CFI已成功应用于一些大型应用程序, 然而CFI理论与实际应用之间仍然存在着较大的差距. 这通常是由许多基于源代码实现的CFI算法需要整个软件生态系统的完整源代码, 以便正确地分析应用程序控制流所导致. 此外, 商用软件范例所共有的复杂控制流, 例如GUI交互, 事件驱动等也为CFI方案的应用带来巨大的挑战[
(3) 目前仍缺少一种针对CFI方案的系统评价方法. 一方面, 不同CFI方案实现的底层硬件设备, 操作系统以及基准测试的选择方面均有差异, 这给不同方案之间的评估造成较大的阻碍; 另一方面, 学界对如何评估CFI方案的安全性尚未达成一致, 缺少一个科学的评价体系来定量地评估CFI方案的防御能力. 因此, 亟需一套统一的、系统的评估方法来对CFI方案进行全面而客观的评价.
http://www.jos.org.cn/1000-9825/5491.htm]]>
http://www.jos.org.cn/1000-9825/5491.htm]]>
王丰峰, 张涛, 徐伟光, 孙蒙. 进程控制流劫持攻击与防御技术综述. 网络与信息安全学报, 2019, 5(6): 10–20. [doi: 10.11959/j.issn.2096-109x.2019058]
Wang FF, Zhang T, Xu WG, Sun M. Overview of control-flow hijacking attack and defense techniques for process. Chinese Journal of Network and Information Security, 2019, 5(6): 10–20 (in Chinese with English abstract). [doi: 10.11959/j.issn.2096-109x.2019058]
https://web.archive.org/web/20140911011045/http://support.microsoft.com/kb/875352/en-us]]>
http://pax.grsecurity.net/docs/aslr.txt]]>
Ray D, Ligatti J. Defining code-injection attacks. ACM SIGPLAN Notices, 2012, 47(1): 179–190. [doi: 10.1145/2103621.2103678]
Roemer R, Buchanan E, Shacham H, Savage S. Return-oriented programming: Systems, languages, and applications. ACM Transactions on Information and System Security, 2012, 15(1): 2. [doi: 10.1145/2133375.2133377]
Burow N, Carr SA, Nash J, Larsen P, Franz M, Brunthaler S, Payer M. Control-flow integrity: Precision, security, and performance. ACM Computing Surveys, 2018, 50(1): 16. [doi: 10.1145/3054924]
武成岗, 李建军. 控制流完整性的发展历程. 中国教育网络, 2016, (4): 52–55. [doi: 10.3969/j.issn.1672-9781.2016.04.031]
Wu CG, Li JJ. Evolution of control flow integrity. China Education Network, 2016, (4): 52–55 (in Chinese with English abstract). [doi: 10.3969/j.issn.1672-9781.2016.04.031]
Li JK, Tong XM, Zhang FW, Ma JF. Fine-CFI: Fine-grained control-flow integrity for operating system kernels. IEEE Transactions on Information Forensics and Security, 2018, 13(6): 1535–1550. [doi: 10.1109/TIFS.2018.2797932]
Jang H, Park MC, Lee DH. IBV-CFI: Efficient fine-grained control-flow integrity preserving CFG precision. Computers & Security, 2020, 94: 101828.
Zhang JL, Qi BH, Qin Z, Qu G. HCIC: Hardware-assisted control-flow integrity checking. IEEE Internet of Things Journal, 2019, 6(1): 458–471. [doi: 10.1109/JIOT.2018.2866164]
Li JF, Chen LW, Shi G, Chen K, Meng D. ABCFI: Fast and lightweight fine-grained hardware-assisted control-flow integrity. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2020, 39(11): 3165–3176. [doi: 10.1109/TCAD.2020.3012640]
Feng L, Huang J, Hu J, Reddy A. FastCFI: Real-time control-flow integrity using FPGA without code instrumentation. ACM Transactions on Design Automation of Electronic Systems, 2021, 26(5): 39. [doi: 10.1145/3458471]
Wang Y, Li QB, Chen ZF, Zhang P, Zhang GM, Shi ZH. BCI-CFI: A context-sensitive control-flow integrity method based on branch correlation integrity. Information and Software Technology, 2021, 136: 106572. [doi: 10.1016/j.infsof.2021.106572]
Abadi M, Budiu M, Erlingsson Ú, Ligatti J. Control-flow integrity principles, implementations, and applications. ACM Transactions on Information and System Security, 2009, 13(1): 4. [doi: 10.1145/1609956.1609960]
http://llvm.org]]>
http://www.jos.org.cn/1000-9825/5058.htm]]>
http://www.jos.org.cn/1000-9825/5058.htm]]>
http://www.jos.org.cn/1000-9825/5829.htm]]>
http://www.jos.org.cn/1000-9825/5829.htm]]>
http://www.jos.org.cn/1000-9825/5496.htm]]>
http://www.jos.org.cn/1000-9825/5496.htm]]>
Qiu PF, Lyu YQ, Zhang JL, Wang DS, Qu G. Control flow integrity based on lightweight encryption architecture. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2018, 37(7): 1358–1369. [doi: 10.1109/TCAD.2017.2748000]
Ge XY, Cui WD, Jaeger T. GRIFFIN: Guarding control flows using intel processor trace. ACM SIGPLAN Notices, 2017, 52(4): 585–598. [doi: 10.1145/3093336.3037716]
Henning JL. SPEC CPU2000: Measuring CPU performance in the new millennium. Computer, 2000, 33(7): 28–35. [doi: 10.1109/2.869367]
Henning JL. SPEC CPU2006 benchmark descriptions. ACM SIGARCH Computer Architecture News, 2006, 34(4): 1–17. [doi: 10.1145/1186736.1186737]
Das S, Zhang W, Liu Y. A fine-grained control flow integrity approach against runtime memory attacks for embedded systems. IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 2016, 24(11): 3193–3207. [doi: 10.1109/TVLSI.2016.2548561]
http://www.winehq.org]]>
https://www.coker.com.au/bonnie++]]>
http://math.nist.gov/scimark2]]>
http://www.cs.virginia.edu/stream/ref.html]]>
http://www.exim.org]]>
Fitzpatrick B. Distributed caching with memcached. Linux Journal, 2004, 124.