Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Efficient Dynamic Tracking Technique for Detecting Integer-Overflow-to-Buffer-Overflow Vulnerability

今天要介绍的一篇论文Efficient Dynamic Tracking Technique for Detecting Integer-Overflow-to-Buffer-Overflow Vulnerability 来自AsiaCCS’15,基于动态信息流技术来检测软件漏洞是安全研究的热点,这篇论文的主要作者是国内南京大学的研究人员,讨论了一个称为Integer-Overflow-to-Buffer-Overflow的漏洞检测。


Introduction

Integer Overflow to Buffer Overflow (IO2BO)

整数溢出导致分配出预期外的内存大小,进而发生缓冲区溢出

常用方法:污点分析,插入overflow checks

会产生大量的误报

IntPatch 现实生活中,当程序被patch后,仍会报错

本文提出 a novel runtime IO2BO detector, IntTracker

和 IntPatch 相似,IntTracker 会根据 critical path 选择所有的整数运算,并通过固定模式的规则排除一些不会发生溢出的运算。IntTracker 发现可能发生整数溢出并不马上报告,而是跟踪数据流,当污染的数据可以到达内存操作,这时才发出溢出警告。

有很低的误报和漏报率

在 IntTracker 中采用了a specific range of very large and rarely used integer values (we call it Dirty-zone) 代替溢出值。

两种 sanitization routines: Santz-postcond: 固定模式,静态检测溢出;Santz-spec:动态

as an exten- sion of the GCC compiler


sanitization routines

postcondition test

Santz-spec

Santz-spec is usually application specific and designed based on developers’ preference, Santz- spec is usually of various patterns and hard to be detect- ed statically.


design of IntTracker

  1. static selection analysis: 根据污点分析方法选择出在critical paths(从污点源到 Mem 运算)上的所有整数运算,并排除被 Santz-postcond 保护的运算

  2. code instrumentation analysis: 在每个算术运算后插入 postcondition test; 在每个 Mem运算前插入dirty value guarding code


Dynamic Protection by IntTracker

保证四个条件

  • PR1

使用 Dirty value 代替溢出值,不会改变程序的语义

溢出很少被程序员故意使用,对于溢出,溢出值本身就是有害的,而溢出值本身对于程序语义并不重要。

  • PR2

当 Dirty value 经过算术运算后,仍在 dirty zone中,保持 dirty value 的性质

根据观察得出 Observation 1. Overflow paths for harmful IO2BO vul- nerabilities are short in general.

assume that normal integer values produced by Arith op are always in a small range (Assumption 1). 根据 Table 3

Here we use [0xA0000000, 0xE0000000) as the Dirty-zone

our designated initial dirty value (i.e. 0xC0000000)

算术运算:Result = Dirty op Delta

根据数据, Delta 在 small range 的概率为0.999997756

证明:

  1. case Result = Dirty * Delta:

    Delta equals to 1 : Dirty Value 不变

    Delta is a value greater than 1 :检测出可能overflow,将溢出值用 Dirty Value 代替

    概率为 1

  2. case Result = Dirty ≪ Delta

    跟例子1相似

  3. case Result = Delta – Dirty

    Delta is a value from Small-zone,检测出可能overflow,将溢出值用 Dirty Value 代替

    If Delta is a value out of Small-zone but also smaller than Dirty Value,检测出可能overflow,将溢出值用 Dirty Value 代替

    If Delta is a value bigger than Dirty,结果几乎不可能在Dirty Zone中

    概率 0.999997756

  4. case Result = Dirty ± Delta

    概率 0.999997756

Therefore after N Arith op’s, we can get P N (I Result ) ≈ (0.999997756)N

  • PR3

Dirty values 能够被 Santz-spec 检测出, 减少误报

Santz-spec 一般用来检测 溢出值和 normal values 的区别

Assumption 1 is well supported by real world scenarios.

因为正常值是一个小的范围,所以通常开发者设定的 thresholds 比起我们很大的 Dirty Value 来说很小,所以Santz-spec 一般能检测出。

  • PR4

当 Dirty value 抵达 Memory 操作,可以被看做溢出的标志

(见Table 4)

Implementation

GCC-4.5.0

The selection analysis works on the GIMPLE IR

∼ 4K lines of C code

能识别的内存操作:

1
2
3
4
5
6
7
8
9
memory allocation routines (such as malloc, al-loc, and realloc)

memory or string copy routines (such as memcpy, strncpy)

memory manipulation routines (such as memset and memmove)

C++ operators such as new[ ]. 

additional memory allocations or block copy routines (for exam-ple, jas_realloc in jasper).

Evaluation


Limitation

  1. 依旧有不能检测出的反例存在

  2. 除法

    In our study on CVE bugs, only 4 out of the 183 cases have divisions appearing along overflow paths and the Delta in all 4 cases are small values 。

  3. test cases of high code coverage and overflow-inducing inputs

    测试中