获课：97it.top/17277/

### 整数溢出技巧：利用有符号与无符号数转换绕过长度检查的实战案例

在底层系统编程与安全攻防领域，整数溢出是一种极具隐蔽性的漏洞类型，常被用于绕过长度校验机制，进而触发缓冲区溢出、堆破坏等严重安全问题。其中，有符号数（signed）与无符号数（unsigned）之间的类型转换，是整数溢出攻击中最经典的技术路径之一。

#### 一、有符号与无符号数的本质差异

在C/C++等系统级语言中，整数类型不仅决定存储空间大小，还影响数值的解释方式。有符号整数采用补码表示，最高位为符号位，可表示负数；而无符号整数将所有位都用于表示数值，仅能表示非负整数。例如，一个8位有符号数signed char的取值范围是-128至127，而unsigned char则是0至255。

当有符号数被转换为无符号数时，系统不会改变其二进制位模式，而是重新解释其含义。例如，-1（补码为0xFF）转换为unsigned int后变为4294967295。这一特性若被恶意利用，可使程序逻辑产生严重偏差。

#### 二、利用负数绕过长度检查的攻击原理

许多程序在进行内存分配或缓冲区操作前会执行长度检查，如：

if (len < MAX_SIZE) { ... }

若len为有符号整数，攻击者可传入一个负值（如-1），在后续转换为无符号整数用于内存分配时，该值会被解释为一个极大的正数（如4294967295）。此时，程序虽通过了“len < MAX_SIZE”的检查（因-1 < MAX_SIZE为真），但实际分配的内存远小于所需，导致后续数据写入时发生堆溢出。

这种攻击的核心在于“检查时”与“使用时”对同一变量的类型解释不一致：检查阶段视为有符号数，而分配阶段视为无符号数，形成“类型语义错位”。

#### 三、实战案例：Expat XML解析器整数溢出漏洞（CVE-2022-22822）

CVE-2022-22822是Expat库中一个典型的整数溢出漏洞，其成因正是整数运算中的类型处理不当。在处理XML命名空间URI时，代码执行如下分配逻辑：

int len = (int)strlen(uri);

XML_Char *temp = (XML_Char *)REALLOC(parser, b->uri,

sizeof(XML_Char) * (len + EXPAND_SPARE));

其中，len为有符号整数，而内存分配函数内部将乘法结果视为无符号整数处理。当len极大时，len + EXPAND_SPARE可能溢出，导致乘法结果远小于预期，最终分配一个极小的缓冲区，却写入大量数据，造成堆溢出。

虽然该案例主要涉及长度过大导致的溢出，但其根本机制与有符号/无符号转换一致：即整数运算结果在不同上下文中被不同方式解释，破坏了安全边界。

#### 四、攻击场景模拟与防御思路

假设一个用户输入处理函数：

void process_input(int len, char *data) {

if (len < 1024) {

char *buf = malloc(len);

memcpy(buf, data, len);

}

}

若len为signed int，攻击者传入len = -1，检查通过（-1 < 1024），但malloc(len)实际分配0xFFFFFFFF字节（在32位系统上），可能分配失败或分配极小内存，而memcpy仍尝试复制“负长度”数据，导致越界写入。

防御此类漏洞的关键在于：统一类型语义，避免有符号与无符号混用；在关键边界检查中，对输入值进行有效性验证，如确保长度非负；使用安全函数（如calloc、strncpy）并结合编译器强化选项（如_FORTIFY_SOURCE）。

#### 五、结语

整数溢出虽不如同缓冲区溢出般直观，但其作为“逻辑层面的越界”，在现代软件安全中依然占据重要地位。理解有符号与无符号数的转换机制，不仅有助于漏洞挖掘，也对构建高可靠系统具有深远意义。在安全编程实践中，类型安全应被视为与内存安全同等重要的基石。