G.O.S.S.I.P 学术论文推荐 2020-01-12

admin 2022年4月23日08:44:37评论16 views字数 1374阅读4分34秒阅读模式

今天给大家推荐的是来自明尼苏达大学的Kangjie Lu老师的研究团队的论文,文章研究的是kernel memory leak的检测,被NDSS 2021录用。

G.O.S.S.I.P 学术论文推荐 2020-01-12

内存泄露是指动态分配的内存对象在其生命周期结束之后没有被释放。内核空间的内存泄露比用户空间的危害更大,未正确释放的内存直至系统重启之前均无法使用,会被攻击者利用以进行拒绝服务攻击。

针对内核代码的内存泄露检测面临以下两个挑战:

  1. 内核不同模块会有其定制的内存管理函数,需要对这些函数进行识别;

  2. 内核中指针的传递涉及复杂且冗长的数据流,需要准确推断变量的生命周期以及释放点。

本文中作者分别针对内存管理函数识别和内存对象所有权推测(ownership reasoning)提出了新的方法,在此基础上使内核内存泄露达到了较好的效果。

G.O.S.S.I.P 学术论文推荐 2020-01-12

作者设计的K-MELD如图2所示,分为Pre-processing、Alloc/Dealloc Detection、Ownership Reasoning和Bug detection四部分:

  1. 在预处理阶段,与常见的源码静态分析工具类似,K-MELD将源码编译为LLVM IR并构建call graph。

  2. 对于内存分配函数的识别,作者观察到大多数分配函数会返回指针并进行null-check,于是以此为模式并利用额外的规则过滤,得到了内存分配函数的集合。在此基础上,利用内核模块的error-handling特性,作者通过{alloc, check, release, return}的模式,在代码的出错处理分支将内存释放函数与分配函数进行对应。

  3. 在所有权推断上,作者分别利用escape analysis和consumer detection来推测内存对象的所有权(即最终负责释放内存的函数)。前者用来判断内存对象的向上传递(即当前函数不负责对内存的释放);后者用来递归向下推测内存的释放点(即最终“消费”指针的函数)。

  4. 最终作者通过模式匹配的方式,判断内存对象在其释放点是否被正确释放,以确认是否存在内存泄露。


作者的测试针对5.2.13版本的Linux kernel进行,将其编译为allyesconfig版本的bitcode。其中:bitcode的生成用了5个小时;内存分配函数的收集用了2个小时;释放函数的识别用了1个小时;对每个分配函数的检查从几秒钟到四小时不等。


作者初始识别出4621个内存分配函数,在释放函数匹配完成之后剩下807个。作者识别的函数可以在这里查看 https://pastebin.com/raw/hBfiqnEp。


K-MELD共产生458个bug报告,其中240个为误报(52%)。作者还选取了17个现有的CVE,K-MELD可以检测到其中的9个。无法检测的结果中,有两个是因为API混淆,一个是由于过于复杂的指针传播,还有四个因为版本变更无法复现。

G.O.S.S.I.P 学术论文推荐 2020-01-12

作者还进一步测试了escape analysis和consumer analysis的影响,在分别禁用两种分析的情况下,工具报告的数量上升到1292和1386个,且随机抽取新增的报告手工分析均为误报,证明两种方法确实有效。


论文链接:https://www-users.cs.umn.edu/~kjlu/papers/k-meld.pdf

原文始发于微信公众号(安全研究GoSSIP):G.O.S.S.I.P 学术论文推荐 2020-01-12

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年4月23日08:44:37
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   G.O.S.S.I.P 学术论文推荐 2020-01-12http://cn-sec.com/archives/923783.html

发表评论

匿名网友 填写信息