高效动态检测：整数溢出防范缓冲区漏洞
171 浏览量
更新于2024-08-27
收藏 821KB PDF 举报
本文探讨了"用于检测整数溢出到缓冲区溢出漏洞的高效动态跟踪技术"。作者 Hao Sun、Xiangyu Zhang、Chao Su 和 Qingkai Zeng 作为来自南京大学的科研团队成员，聚焦于在C/C++程序中识别和防范Integer-Overflow-to-Buffer-Overflow (IO2BO)漏洞。这种漏洞可能被攻击者利用，对计算机系统造成严重损害。
IO2BO漏洞是由于整数运算过程中溢出导致的，它通常发生在从用户输入读取值的程序点（源点）到内存分配站点（汇点）之间的关键路径上。为了有效地检测这类漏洞，研究人员提出了IntTracker，一种高效的动态追踪技术。IntTracker的核心原理是静态污点分析，通过这种方法，系统能够筛选出那些可能引发溢出的整数操作，特别是那些沿程序执行路径上的关键操作。
IntTracker的实现包括以下几个关键步骤：
1. **漏洞识别**：通过源代码分析，确定可能的溢出源，即从用户输入获取数值的地方，这涉及对程序逻辑的深入理解。
2. **数据流分析**：在编译期间或运行时，IntTracker追踪整数变量的值如何在程序中流动，识别可能的溢出点，即当数值超出其预定范围时的操作。
3. **动态监控**：通过在关键操作点上插入监控机制，实时检查整数运算结果是否超出边界，如果发现溢出迹象，触发警报或采取进一步的防护措施。
4. **性能优化**：考虑到效率问题，该技术设计得尽可能减少对程序执行的影响，确保在不影响正常功能的前提下进行漏洞检测。
5. **报告与反馈**：当检测到潜在的IO2BO漏洞时，IntTracker会生成详细的报告，供开发人员诊断和修复问题。
IntTracker的优势在于其能够早期发现和阻止潜在的IO2BO攻击，增强软件安全性，同时保持了良好的性能平衡。通过将静态分析与动态监控相结合，这种方法对于现代软件开发中的安全防护具有重要意义，有助于保护系统免受恶意攻击。
from a specific range of very large and rarely used integer
values (we call it Dirty-zone). It is analogous to poisoning
the value. IntTracker only reports when a poisoned value
reaches a memory sink. Note that 1) all integer operations
along the propagation path of a poisoned value would not
change its poisonous feature (as proved in Section 2.3.3);
2) if there is any sanitization routine along the propagation
path of a poisoned value, the propagation can be automat-
ically stopped due to the fact that the poisoned value falls
out of the legitimate range allowed by the check. In other
words, IntTracker can reduce the false positives introduced
by sanitization routines.
Our contributions are highlighted as follows.
1. We define sanitization routines into two categories:
Santz-postcond which uses fixed patterns to catch over-
flows and can be identified through static analysis, and
Santz-spec which leverages specific program character-
istics to sanitize overflown values and are left for our
dynamic technique to handle.
2. We propose a novel efficient dynamic tracking tech-
nique. It uses very large and rarely used dirty val-
ues as the indicator of overflows, which allows natural
propagation and sanitization of overflown values.
3. We implement a prototype, IntTracker, as an exten-
sion of the GCC compiler [2]. Static taint analysis is
used to select integer operations along critical paths.
It also checks the presence of fixed patterns of widely
used sanitizations to exclude parts of the selected in-
teger operations. IntTracker detects integer overflows
through postcondition test [41][33]. Once an integer
overflow is detected, IntTracker poisons the overflown
value. Guards are inserted to memory sinks to detect
if poisonous values can reach these sinks.
4. Experimental results show that IntTracker is effective
in detecting harmful IO2BO vulnerabilities while by-
passing un-harmful ones, which substantially improves
the state of the art. Specifically, IntTracker could catch
all the 600 IO2BO vulnerabilities in the SAMATE’s
Juliet test suite [26] and 14 harmful IO2BO bugs in
real world. Furthermore, as for the patched code for
20 real-world IO2BO bugs with sanitization routines,
IntTracker only reports one IO2BO (i.e. one false posi-
tive) whereas IntPatch reports all of them. At last, Int-
Tracker has a negligible performance overhead (0.69%
on average).
Outline. The rest of this pap er is organized as follows. Sec-
tion 2 presents the design of IntTracker. Section 3 describes
implementation details. Section 4 presents the experimental
results. Limitations, related work and conclusion are dis-
cussed in Section 5, Section 6 and Section 7, respectively.
2. DYNAMIC TRACKING TECHNIQUE
2.1 Problem Definition
Inspired by discussions in Section 1, the occurrence of an
IO2BO vulnerability can be described as a process, in which
tainted data is first introduced by the user at a source point,
then overflow occurs at some point along its propagation to
a memory sink. Along its propagation path, tainted data
harmful IO2BO := Taint-source; [Arith_op;]
N
IO_op; [Arith_op;]
M
MEM;
anticipated IO2BO := Taint-source; [Arith_op;]
N
IO_op; Santz;
IO_op, Arith_op {+, -, *, <<}
MEM {malloc, memcpy, strncpy, realloc, }
Figure 1: IO2BO vulnerability description.
Table 1: Postcondition test. The subscript s indi-
cates a signed operation; the subscript u indicates
an unsigned operation.
Arith op Postcondtion Test
x = o
1
+
s
o
2
(o
1
> 0
∧
o
2
> 0
∧
x > 0)
∨
(o
1
< 0
∧
o
2
< 0
∧
x > 0)
x = o
1
+
u
o
2
x < o
1
∨
x < o
2
x = o
1
−
s
o
2
(o
1
< 0
∧
o
2
> 0
∧
x > 0)
∨
(o
1
> 0
∧
o
2
< 0
∧
x < 0)
x = o
1
−
u
o
2
o
1
< o
2
x = o
1
∗
s/u
o
2
x = 0
∧
x/o
1
= o
2
x = o
1
≪ o
2
x ≫ o
1
= o
2
would undergo a number of integer arithmetic operations.
Therefore, we can formally define the process of an IO2BO
vulnerability as shown in Figure 1.
Specifically, Taint-source denotes program points reading
values from users. It is the start of an IO2BO vulnerability,
introducing tainted (untrusted) data into programs. MEM
is memory manipulation routines, acting as sinks for taint-
ed data. Arith op and IO op are the operations on taint-
ed data along the path from Taint-source to MEM. Here,
we only consider arithmetic operations which could change
the concrete value of tainted data
2
. The superscript N and
M indicate the corresponding operation might occur several
times. IO op is the point where an integer overflow happens,
including addition, subtraction, multiplication and left-shift
operations in either signed or unsigned type. In addition,
as for anticipated IO2BOs, Santz indicates sanitization rou-
tines that are used to prevent overflown data from flowing
into MEM.
Our goal is to detect harmful IO2BOs and bypass the
anticipated IO2BOs.
2.2 Sanitization Routines
Experienced developers often anticipate the possibility of
overflows and insert sanitization routines after the overflow
sites to prevent overflown values from affecting further pro-
gram execution.
Postcondition test [33] is widely used as sanitization rou-
tines by developers to prevent integer overflows in advance
or to patch buggy code. The intuition of postcondition test
is to utilize the mismatch between an overflown value and
the expected value to detect overflow. We call them Santz-
postcond for short. Table 1 shows the details. As Santz-
postcond is of fixed patterns, we may exclude the check-
s for some Arith op’s by checking statically whether Santz-
postcond is present after them.
Meanwhile, there also exist other sanitization routines,
where developers usually leverage program characteristics
and employ program specific checks to sanitize overflown
2
Note that we do not consider division as Arith op just like
IntPatch [41]. Divisions are very rare along critical paths
according to our study of the 183 CVE IO2BO bugs.
485
剩余11页未读，继续阅读
2021-09-16 上传
2022-08-08 上传
2022-11-14 上传
点击了解资源详情
点击了解资源详情
点击了解资源详情
点击了解资源详情
点击了解资源详情
点击了解资源详情
weixin_38671628
- 粉丝: 9
- 资源: 942
我的内容管理
展开
最新资源
- JHU荣誉单变量微积分课程教案介绍
- Naruto爱好者必备CLI测试应用
- Android应用显示Ignaz-Taschner-Gymnasium取消课程概览
- ASP学生信息档案管理系统毕业设计及完整源码
- Java商城源码解析：酒店管理系统快速开发指南
- 构建可解析文本框：.NET 3.5中实现文本解析与验证
- Java语言打造任天堂红白机模拟器—nes4j解析
- 基于Hadoop和Hive的网络流量分析工具介绍
- Unity实现帝国象棋：从游戏到复刻
- WordPress文档嵌入插件：无需浏览器插件即可上传和显示文档
- Android开源项目精选：优秀项目篇
- 黑色设计商务酷站模板 - 网站构建新选择
- Rollup插件去除JS文件横幅：横扫许可证头
- AngularDart中Hammock服务的使用与REST API集成
- 开源AVR编程器：高效、低成本的微控制器编程解决方案
- Anya Keller 图片组合的开发部署记录
