jsp做的当当网站的文档,专业电子科技网站建设,wordpress关联博客,网店装修店面RemarksConference: NDSS 2020Full Paper: HFL: Hybrid Fuzzing on the Linux KernelSummary针对的问题#xff1a; Linux 操作系统内核安全漏洞的发现需要新技术。现有解决方案的不足#xff1a;当前的模糊测试技术难以直接应用于内核安全漏洞发现。提出的创新方案概述…RemarksConference: NDSS 2020Full Paper: HFL: Hybrid Fuzzing on the Linux KernelSummary针对的问题 Linux 操作系统内核安全漏洞的发现需要新技术。现有解决方案的不足当前的模糊测试技术难以直接应用于内核安全漏洞发现。提出的创新方案概述解决内核安全漏洞发现过程中的三大挑战1 具有由系统调用参数确定的间接控制传输2通过系统调用控制和匹配内部系统状态3推断用于调用系统调用的嵌套参数类型。提出一种基于混合模糊测试技术的内核安全漏洞发现技术。达到的效果在最新的 Linux 内核中 发现 24 个新型安全漏洞 漏洞发现速率提高 3 倍以上。代码覆盖率比Moonshine提升15%比Syzkaller提升26%。IntroductionLinux其内核庞大导致存在很多未知的漏洞 而这些内核安全漏洞影响巨大迫切需要创新的技术提升当前的漏洞发现率 。本文创新发展的混合模糊测试技术一直是近年来漏洞发现领域的研究热点技术价值正在逐步展现值得漏洞挖掘相关研究人员跟踪、掌握该技术用于现有研究工作中。本文的主要贡献有第一个可以应用于内核测试的混合模糊测试工具。解决内核安全漏洞发现过程中的三大挑战1 具有由系统调用参数确定的间接控制传输2通过系统调用控制和匹配内部系统状态3推断用于调用系统调用的嵌套参数类型。提出一种基于混合模糊测试技术的内核安全漏洞发现技术。在最近的 Linux 内核中 发现 24 个新型安全漏洞 漏洞发现速率提高 3 倍以上。代码覆盖率比Moonshine提升15%比Syzkaller提升26%。Motivation混合模糊测试结合了模糊测试和符号执行的优点避免了各自一定的缺陷是挖掘二进制漏洞的有力工具。但是在Linux内核的测试上不论是单独地模糊测试单独地符号执行或者是混合模糊测试都无法取得很好的结果这是由于Linux内核的机制比常规的软件有很多特殊的地方。本文总结了三个特定于内核的挑战。挑战一为了支持大量的设备Linux内核中大多数组件都和抽象接口实现层解耦合一般来讲接口层用于访问特定功能的实现这方面与对象编程相似。Linux内核代码中有运行时多态性和编译时多态性借用C中的多态概念来分析运行时多态是指程序运行时才可确定的多态性主要通过继承和虚函数获得。Linux构建一个函数指针表抽象接口其中包含一系列指向具体实现的函数指针在运行时候执行某种操作从函数指针表抓取某个指针由当时具体的对象类型决定在编译阶段不能确定系统调用哪个函数也被称为滞后联编或动态绑定典型的例子就是虚拟文件系统。编译时多态性主要通过重载机制获得。可在执行前通过静态分析提升测试效果。但是运行时多态性之前没有有效的办法解决。Fuzzer无法用输入的索引值来获取函数指针表中的指针。符号执行也不能解决。挑战二利用fuzzing技术测试内核操作系统一般都是以系统调用作为输入因为系统调用是用户态和内核态交互的关键。并且内核的系统调用是上下文依赖的需要在特定的内部状态下。而不考虑上下文依赖的系统调用往往会直接被拒绝无法进入下一步测试。对于符号执行技术由于内核的系统状态需要很多数据变量维持符号执行容易遭遇状态爆炸问题。挑战三Linux内核中大量的系统调用的参数都是嵌入式结构比如某个参数字段的内容指向另外一个结构这样的嵌入式结构的系统调用的各个参数的语义很难猜测因此输入很难构造更难以把输入模板化。当前的一些内核模糊测试技术并没有很好的解决上述的问题。如下图所示。IMF使用系统调用跟踪来分析系统调用顺序以期望解决上述挑战二。MoonShine通过静态分析来推断系统调用依赖。DIFUZE通过静态分析来推断完整系统调用参数的类型。这些静态分析的方法无法准确的推断处结果因为某些参数是须在运行时才能确定的。Approach总体来讲HFL的设计遵循了用户级混合模糊测试技术的设计将传统的模糊和符号执行结合起来。HFL的总体运行流程如下图所示。HFL的特征有Kernel Syscall FuzzingCoverage Guided FuzzingSymbolic Analyzer。前面两个特征在内核模糊测试中很常见就不赘述了。对于Symbolic Analyzer传统的混合模糊测试中如何判定fuzzing遇到hard constraint再切换到symbolic execution一直是一个难点。在HFL中其fuzzer通过维护一个频度计数表在测试期间统计用户程序一系列的系统调用执行时条件判断语句的true or false频度以此来判定程序是否被“卡住”。对于一个用户程序执行过程中越是先出现的分支判断低频度越要重视因为他的非条件可能会触发更多的代码覆盖。针对内核的模糊测试本文提出了以下解决方法将间接控制转化为直接控制-转换原始内核。推断系统调用序列建立一致的系统状态-缩小变量符号化的范围。确定系统调用时的嵌套参数类型-在运行时检索嵌套的系统调用参数。下面具体讲HFL如何解决Motivation中提到的三个挑战把指针的间接控制流转换成直接控制流HFL提出了一个基于内核源代码操作的offline translator。在保证条件分支语义的同时将间接的控制流转换为直接的控制流这样内核底层的调用代码块都可以直接被访问而不需要在执行时才确定虚函数具体由哪个函数实现。具体做法是在编译的时候遍历所有的指令对于间接控制流执行以下步骤(1)离线转换器确保函数指针表的索引变量来源于系统调用的参数即是由系统调用的参数决定某个功能的实现这种情况不是这种情况的索引变量对fuzzer执行并无影响。HFL通过执行过程间数据流分析来跟踪系统调用的参数是如何传播以确定是否需要转换。(2)确定索引的值以后结合给定的函数表HFL对每个索引值进行分支变换类似指令编译优化的循环展开通过插入一个条件转移到相应的函数指针上。至此控制流便由间接转为直接方便fuzzer测试。为了推断处合适的系统调用顺序和系统调用依赖HFL首先在内核上进行静态分析获取可能存在依赖的系统调用组然后再验证这些潜在的依赖组以筛选出真正的依赖关系。HFL对目标内核进行指针分析pointer-analysis收集一对读/写操作即其中一条指令执行读指令另一条指令执行写指令两条指令都是从相同的内存位置读取和写入这样的读/写操作就被称为候选依赖对。但是pointer analysis存在误报问题因此在执行内核时符号化地执行这些潜在依赖项对时HFL检查他们是否访问相同的地址这样就能确定是否存在正在的依赖然后就能确定合适的系统调用顺序。与以往的内核测试不一样的是HFL除了确定系统调用顺序外还使用符号约束信息来自系统调用参数的符号化来保证那些系统调用参数之间的依赖。HFL的fuzzer和symbolic analyzer之间联系紧密执行过程中交互密切相辅相成直接测试结束。HFL使用concolic executor和内核特有知识来检索复杂的嵌套参数结构。在嵌套结构中(1)连接到嵌套输入结构的内存位置和(2)内存缓冲区参数的长度这两个参数是系统调用构建的关键。HFL在concolic执行时不断监视传递函数的调用一旦被调用就检查传递函数的源缓冲区是否收到了符号污染这样就能确定来自我们感兴趣的系统调用的传递函数然后就能确认参数指向的缓冲区HFL使用符号状态来跟踪某个位置的偏移值最后就能确定内存位置。同时也可以通过跟踪传递函数的参数值来获得缓冲区的长度。Reflection本文提出的解决方法对于非内核的二进制程序测试也有帮助比如大量用c虚函数实现的多态和继承的二进制程序比如本身带有大量嵌套结构的二进制程序等都可以借鉴HFL的方法精神。按理来说先解决前面的分支问题较为重要但是如QYSM所讲会出现过度约束问题导致前面的约束条件满足了后面的条件约束无法满足反而会降低代码覆盖率。当后面的函数路径并不依赖前面的分支时即为过度约束下面这个例子出自QYSM论文。解决过度约束这个问题的办法就是部分求解约束即从最后一个条件开始倒推着求解约束。因此这是一个需要权衡的问题。
