记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华

Check It Again: Detecting Lacking-Recheck Bugs in OS Kernels

2018-11-28 02:25

原文:https://www-users.cs.umn.edu/~kjlu/papers/lrsan.pdf

作者:Wenwen Wang, Kangjie Lu, and Pen-Chung Yew

出处:ACM CCS’18

1. 论文简介

论文中,作者主要介绍分析操作系统内核中的LRC(lacking-recheck)类型jbug。并介绍了自己设计的一个静态分析系统LRSan(在Linux上实现),用于检测操作系统内核中的LRC bug。

本文的主要贡献: 1. 定义了LRC bugs,并第一次展示了关于LRC bug的深入研究。 2. 实现一个自动化的LRÇ bug检测系统(LRSan),基于LLVM,使用在Linux内核上,可以检测内核中的LRC bug。LRSan运用了很多新的程序静态分析技术。结果显示LRSan在Linux内核发现了2808个LRC case,检测耗时为4小时。并且作者会将它开源。 3. 识别Security check和critical variable的方法。 4. 发现了Linux内核中的19个新的LRC bug。

2. LRC Bugs

如下图所示是LRC Bug形成原因的流程。

如下图所示是一个LRC Bug的例子,其中的val就是critical variable。在第10行中val被进行了security check,但是在第16至19行中val被进行了修改,在第22行中val又被使用了,然而在使用前没有进行recheck。

作者对LRC bug的定义:

  • 拥有一个check-use chain。即执行路径中有对变量进行安全检查,并在之后对变量进行使用。
  • 变量有被修改的可能. 变量在过了前面的security check后,在check-use chain中被修改。
  • 缺少recheck。在变量过了安全检查后,如果在使用前又进行了安全检查,那即是在中间被修改了,也是安全的。因此缺少recheck也是LRC bug的成因之一。

在执行路径上,通常变量的的security check和使用是比较复杂也可能比较远的,尤其是在处理涉及到用户空间和内核空间的多个变量时,因此LRC Bug在操作系统内核中是很常见的。

对security-checked变量的修改可能有如下一些情况导致: 1. Kernel race:操作系统内核通常为线程进程维护了很多共享的数据结构。通常来说很难保证security checked variable不被修改。 2. User race:从用户空间抓取数据通常很容易被通过用户控件的多进程来进行修改。 3. Logic errors:一些逻辑问题可能导致线程本身不正确地将security-checked variable给修改了。 4. Semantic errors:例如类型转换和整数溢出的一些语义错误可能导致security-checked variable被修改。

3. LRSan设计

LRSan的整个结构和Workflow如下图所示,输入为内核源码编译后的LLVM IR。LRSan预处理时会构建一个全局的call-graph,用来进行inter-procedural analysis,并且标注了error codes。LRsan包括了4个关键部分:1. Security check identification,2. Critical variable inference,3. check-use chain construction,4. modification inference。

LRSan在检测Security Check时是基于一个观察,即如果Security check失败了,操作系统内核通常就会返回一个error code,反之则继续执行。因此把Security check定义为一个check statement(例如if语句)。Check statement后面通常会跟两个分支,一个分支会导致返回error code,另一个分支则是继续程序的执行。通过这种方法,LRSan可以自动化地寻找出Security check,并且将checked variable定义为Critical variable。

LRSan也运用了回溯的分析去递归地找到“source” variable。然后LRSan通过数据流分析来找到Critical variable被使用的地方。这样,Check-use chain(从被check到use)就可以确定下来了。

然后LRSan会遍历这些执行路径,寻找出可能的对Critical variable的修改,如果修改被找到了,那么LRSan将会再确认是否在修改后有进行Recheck,如果没有进行Recheck,那么就会将其认定为是一个潜在的LRC case。最后作者对其人工地进行确认核实。

4. LRSan实现

作者基于LLVM 6.0.0实现了LRSan。整个实现中包括两个独立的pass(大约3000行代码)。First pass是用来收集和准备静态分析锁需要的信息,例如构建global CFG,alias results。Second pass是用来进行静态分析检测LRC case的。

5. 评估

5.1 Effectiveness

如下图所示,是LRSan在Linux kernel里找到的19个LRC bug。

5.2 Efficiency

LRSan测试时所用的LLVM IR是用Linux-4.17的源码编译的。作者实验时用的host为一个主存32G的Ubuntu16.04,Quad-Core 3.5 GHz Intel Xeon E5-1620 v4处理器,总共用了4个小时。其中超过80%的时间都是用在first pass(例如信息收集),因为first pass需要构建一个全局的CFG,并收集alias-analysis results。由于这两个过程是没有依赖关系的,因此其实可以把他们并行处理。而且first pass实际上只需要运行一次,因此可以对它进行重用,从而节省时间。

知识来源: https://www.securitygossip.com/blog/2018/11/27/check-it-again-detecting-lacking-recheck-bugs-in-os-kernels

阅读:92073 | 评论:0 | 标签:无

想收藏或者和大家分享这篇好文章→复制链接地址

“Check It Again: Detecting Lacking-Recheck Bugs in OS Kernels”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

九层之台,起于累土;黑客之术,始于阅读

推广

工具

标签云

本页关键词