【论文阅读】Dytan: A Generic Dynamic Taint Analysis Framework

污点源（Source）#

污点源是对程序数据（内存位置）的描述，这些数据应初始化为带有污点标记。内存位置可具有不同的类型，包括变量名、函数返回值，以及从文件或网络连接等 I/O 流中读取的数据。框架支持如下方式指定内存位置：

• 变量与内存偏移量：通过指定变量名及作用域（全局或程序局部），指示某个内存区域应被标记为受污点状态。
• 特定函数的返回值：直接指定函数名称，表明该函数的返回值必须带有污点标记。
• 某种类型的 I/O 流：只需指定流类型，从该类流中读取的数据即被标记为”受污点”状态。
• 特定的 I/O 流：指定来自某个特定 I/O 流的数据必须带有污点标记。

传播策略（Propagation Policy）#

传播策略用于描述程序执行过程中污点标记应如何传播。污点传播可概括为：给定一条语句 s，由 s 生成的数据所对应的污点标记，是与该数据相关联的污点标记经过某个映射函数运算的结果，该函数影响着 s 的执行结果（受影响数据）。生成数据可以明确地识别——它是指存储在寄存器或内存中、其值因执行 s 而发生改变的数据集合；而识别受影响数据以及定义映射函数，同样存在多种方式。为了给框架足够的灵活性，论文允许用户对这两个方面分别进行指定：

• 识别受影响数据：可选择以下两种方式之一——基于数据流的方式，或基于数据流与控制流结合的方式。前者仅考虑污点标记的显式传播，后者还考虑隐式传播。
• 定义映射函数：通常，受影响数据集包含若干带有多个污点标记的数据项。此时框架的默认行为是为生成的数据添加一个包含所有此类污点标记并集的污点集合。然而根据应用场景的不同，污点标记的传播方式多种多样：例如，为每个数据项维护一组独立的污点标记；或根据数据项之间预定义的”包含”层级关系对污点标记进行合并；还有一种则是根据受影响数据特有的污点标记集合，为生成的数据生成新的污点标记。

汇聚点（Sink）#

从宏观角度来看，汇聚点是代码中的一个位置，用户希望在该位置对一个或多个内存位置上的污点标记执行某种检查。汇聚点具有四个特征：

1. 一个 ID：用户为某个汇聚点（或一组汇聚点）分配的整数值，其用途将在下文讨论检查操作时阐明；
2. 一个内存位置；
3. 一个代码位置；
4. 在该代码位置上，利用与该内存位置关联的污点标记执行的一个或多个检查操作。

框架提供了两种主要方式来指定汇聚点的内存位置和代码位置：

• 独立指定：内存地址与代码位置分开指定。与指定污点源类似，内存位置可采用直接指定内存区域、指定过程名及参数索引（针对形式参数）或指定函数名（针对返回值）等方式；代码位置亦可通过多种方式指定。
• 按指令类型指定：适用于用户希望在执行每条特定类型指令（例如系统调用或跳转指令）之前，对污点信息进行分析的场景。

x86 的寄存器重叠问题（Partial Registers）#

x86 架构最让人头疼的就是寄存器混用与重叠。例如，32 位的 EAX 寄存器包含了 16 位的 AX，而 AX 又被拆分为 8 位的 AH（高位）和 AL（低位）。

• 痛点：如果在 AL 中写入了带污点标记的数据，EAX 的低 8 位也随之被污染，但高 24 位可能是干净的。传统的粗粒度（基于整个寄存器）污点跟踪会产生大量的误报（False Positives）。
• Dytan 的解决策略：放弃”以寄存器为单位”的跟踪，建立一个影子寄存器数组（Shadow Register Array），将所有通用寄存器完全”展平”，严格在字节级别（Byte-level）维护污点。这样向 AL 写入污点时，只会精确修改数组中对应的那一个字节的标记，完美解决了局部寄存器的混淆问题。

桥接控制流：处理 EFLAGS 状态寄存器#

在很多 RISC 架构中，“比较”和”跳转”由一条指令完成；但在 x86 中它们是分离的：先用 CMP eax, ebx 修改状态标志位（EFLAGS 寄存器中的 ZF、SF 等），再用 JE（Jump if Equal）根据标志位进行跳转。

• 痛点：如果不跟踪 EFLAGS，一旦遇到条件跳转，污点传播链条就断了。
• Dytan 的解决策略：将 EFLAGS 也视为一种特殊的”影子寄存器”进行精确建模：
  1. 当执行 ALU（算术逻辑）指令或比较指令时，如果源操作数带有污点，就把污点标记传播给 EFLAGS；
  2. 当后续执行条件跳转指令（Jcc）或条件传送指令（CMOVcc）时，读取 EFLAGS 的污点状态——如果启用了控制流传播（Control Flow Tainting），这个污点就会被附加到当前控制依赖图（CDG）的执行上下文中，从而成功把 x86 的底层硬件流与高层的控制流逻辑连接了起来。

化繁为简：海量 x86 指令集的抽象#

x86 是典型的 CISC（复杂指令集），拥有成百上千条长短不一的指令。如果为每一条 ADD、SUB、MOV、XOR 等指令单独编写污点传播规则，工程量巨大且容易出错。

• Dytan 的解决策略：利用 Intel Pin 提供的抽象 API，不再死磕具体的指令助记符，而是通过”操作数属性”来推导语义：
  • Dytan 在运行时（JIT 编译时）检查每条指令：它有几个源操作数（Source Operands）？几个目的操作数（Destination Operands）？它是读内存还是写内存？
  • 基于这些通用属性，直接套用上一节的传播公式（即：目的操作数污点 = 源操作数污点的并集）。这种设计赋予了 Dytan 极强的通用性——哪怕遇到它不认识的冷门指令，只要 Pin 能解析出它的读写意图，污点传播就不会出错。

高级内存传播机制（Shadow Memory 与多重标记）#

x86 支持极其复杂的内存寻址方式（比如 [Base + Index*Scale + Displacement]）。

• Dytan 的解决策略：
  • Dytan 在进程的虚拟地址空间之外，分配了一块巨大的影子内存（Shadow Memory），应用程序内存中的每一个字节，在影子内存中都有一个对应项。
  • 重点突破：与当时其他工具不同（如 TaintCheck 只能记录 0 和 1 代表是否污染），Dytan 是为”通用”而生的，它支持多重污点跟踪（Multi-tagging）——影子内存里存的不是简单的 bit 位，而是指向”污点集合（Taint Mark Set）“的指针。通过位图（Bitmaps）或集合数据结构，Dytan 可以同时告诉你：“这个内存字节，既受到了输入源 A 的污染，也受到了输入源 B 的污染。”

1. 污点源（Sources）#

• 定义：将程序中所有硬编码字符串（Hard-coded strings）作为 Sources，赋予代表”完全信任”的标记（Trust marking）；同时也支持开发者手动指定其他信任源（如受信任文件）。
• 实验具体实现：直接在二进制代码中，将存放硬编码字符串的内存地址（Memory locations）指定为 Sources。

2. 传播策略（Propagation Policy）#

• 定义：仅关注数据流（Data-flow）的传播，忽略控制流。
• 实验具体实现：采用 Dytan 标准的数据流传播规则。当硬编码字符串（如 SQL 语句模板 SELECT * FROM users WHERE id=）被复制、拼接或传递时，其”信任标记”会沿着数据流保守地传播给新的字符串变量。

3. 汇聚点（Sinks）#

• 定义：数据库访问接口，即代码中调用 API 向数据库提交 SQL 查询的函数调用点；关注的变量是即将提交的 SQL 查询字符串参数。
• 检查逻辑（Checking Operation）：在 Sink 处拦截查询参数并解析该 SQL 语句，验证构成 SQL 关键字（如 SELECT、WHERE）和运算符（如 =、OR）的每一个字符是否都带有”信任标记”。
  • 逻辑效果：如果 SQL 关键字是由外部输入（无信任标记）构造或改变的，就说明发生了 SQL 注入；如果外部输入只充当了纯参数值，则校验通过。