高效动态检测：整数溢出防范缓冲区漏洞
195 浏览量
更新于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 上传
2020-06-23 上传
2022-11-14 上传
2023-06-09 上传
2023-09-01 上传
2023-06-09 上传
2023-05-23 上传
2023-10-26 上传
2023-06-09 上传
weixin_38671628
- 粉丝: 9
- 资源: 942
我的内容管理
展开
最新资源
- IEEE 14总线系统Simulink模型开发指南与案例研究
- STLinkV2.J16.S4固件更新与应用指南
- Java并发处理的实用示例分析
- Linux下简化部署与日志查看的Shell脚本工具
- Maven增量编译技术详解及应用示例
- MyEclipse 2021.5.24a最新版本发布
- Indore探索前端代码库使用指南与开发环境搭建
- 电子技术基础数字部分PPT课件第六版康华光
- MySQL 8.0.25版本可视化安装包详细介绍
- 易语言实现主流搜索引擎快速集成
- 使用asyncio-sse包装器实现服务器事件推送简易指南
- Java高级开发工程师面试要点总结
- R语言项目ClearningData-Proj1的数据处理
- VFP成本费用计算系统源码及论文全面解析
- Qt5与C++打造书籍管理系统教程
- React 应用入门：开发、测试及生产部署教程
