读软件开发安全之道：概念、设计与实施14低级编码缺陷

1. 低级编码缺陷

1.1. 在更靠近机器级别的代码中常会出现这类缺陷

• 1.1.1. 越接近硬件级别越能获得最大效率的诱惑仍然很大

• 1.1.2. 更接近硬件级别的编程是非常强大的，但其代价是工作量和脆弱性的增加

1.2. 当数据超出了固定的大小，或者超出了分配的内存缓冲区容量时，就会出现这类问题

2. 算术漏洞

2.1. 不同编程语言在定义其算术运算时有所不同，这种不同体现在数学上或处理器的相应指令上

2.2. 浮点数运算的范围比整数运算的范围更大，但其有限的精度也会导致意外的结果

2.3. 定宽整数漏洞

• 2.3.1. 定宽整数是包括Java和C/C++在内的许多语言中最基本的构建块，如果计算超出了定宽整数的限制范围，你将得到错误的结果

• 2.3.2. 安全性的底线在于我们要了解语言规范，并且避免出现有可能未定义的计算

• 2.3.2.1. 不要耍小聪明，试图找到某种方法来检测未定义的结果，因为在不同的硬件或新版本的编译器上，你的代码可能会停止工作

• 2.3.3. 错误的计算结果会让代码出现各种问题，并且这些问题通常会像雪球一样越滚越大，形成一连串的功能障碍，并最终导致系统崩溃或蓝屏

• 2.3.4. 程序员最好能在代码执行任何有可能超出范围的计算之前解决这些问题，并且保证所有数字都在范围之内

• 2.3.4.1. 解决问题最简单的方法是使用比有可能出现的最大值还要大的整数空间，然后检查并确保无效值永远不会悄悄潜入

• 2.3.5. 将计算分解，以便在乘法和除法中使用64位计算，并向下转换为32位结果

• 2.3.6. 最干净的解决方案是将所有变量都升级为64位，代价是降低一点效率

• 2.3.7. 这就是使用定宽整数进行计算所涉及的权衡

2.4. 浮点精度漏洞

• 2.4.1. 浮点数在很多方面都比定宽整数更强健，并且限制更少

• 2.4.2. 当超出这个极大的范围时，你会得到一个有符号的无穷大或NaN（Not a Number，不是数字）反馈，而不是像定宽整数那样对值进行截断

• 2.4.3. 1/10在二进制中是一个无限循环小数（即0.00011001100…以1100无限循环）​，所以最低位会出现错误

• 2.4.3.1. 这些错误都是在低位引入的，因此称为下溢(underflow)

• 2.4.4. 错误不会带来重大影响，但是当需要全精度时，或者当计算中纳入不同数量级的值时，优秀的编码人员会格外谨慎

• 2.4.5. 当无法精确表示结果值时，低位少量的错误也会一直累积

• 2.4.5.1. 尽可能永远不要使用浮点值来比较值是否相等（或不相等）​，因为这种操作无法容忍计算值的微小差异

• 2.4.6. 当你必须使用高精度时，请考虑使用超高精度浮点表示法（IEEE 754中定义了128位和256位格式）​

• 2.4.6.1. 任意精度的十进制或有理数表示都可能是最佳选择

2.5. 安全算术

• 2.5.1. 整数溢出比浮点下溢更容易出现问题，因为它会带来差别很大的结果，但我们也不能认为浮点下溢很安全而忽略它

• 2.5.2. 使用类型转换时要谨慎，因为它有可能像执行计算一样导致截断或改变结果

• 2.5.3. 任何情况下，尽可能限制计算的输入，确保所有可能出现的值都是可以正确表示的

• 2.5.4. 使用较大的固定的整数来避免可能出现的溢出；在将结果转换为较小的整数之前，检查结果是否在范围内

• 2.5.5. 要记住，即使最终结果始终在范围内，计算的中间值也有可能会溢出，从而导致问题

• 2.5.6. 在检查安全敏感代码及其周围的算术正确性时要格外谨慎

3. 内存访问漏洞

3.1. 大多数编程语言都提供了完全托管的内存分配，并设置适当的边界来限制其访问

3.2. 指针允许通过地址直接访问内存，这可能是C语言中最强大的功能

3.3. 缓冲区溢出

• 3.3.1. 当代码访问的内存位置在预期的目标缓冲区之外时，就会发生缓冲区溢出（buffer overflow或buffer overrun）​

• 3.3.2. 缓冲区(buffer)是表示内存中任意区域的通用术语：数据结构、字符串、数组、对象或任何类型的变量

• 3.3.3. 访问(access)是读取内存或写入内存的统称

• 3.3.4. 缓冲区溢出指的是在预期内存区域之外，对内存进行读取或写入

• 3.3.5. 缓冲区溢出并不是堆内存独有的，而是任何类型的变量都有可能发生的，包括静态分配和栈上的局部变量

• 3.3.6. 缓冲区溢出bug会意外地读取内存，这可能会将信息泄露给攻击者，或者导致代码行为异常

• 3.3.7. 不要低估执行显式的内存分配、范围内访问，以及精准释放未使用的内存的难度和重要性

• 3.3.7.1. 使用简单模式来分配、使用和释放是最好的，其中包括异常处理，以确保不会跳过释放操作

• 3.3.7.2. 当一个组件给其他代码的引用分配内存时，一定要定义随后内存释放的责任，将其释放到接口的一侧或另一侧

• 3.3.8. 即使是在包含完全范围检查、垃圾收集等功能的语言中，你仍会遇到麻烦

• 3.3.8.1. 任何直接在内存中修改数据结构的代码都可能会导致与缓冲区溢出类似的问题

3.4. 要想降低这种内存意外泄露的风险并不难，但我们必须覆盖有可能发生泄露的数据结构中的所有字节

• 3.4.1. 不要试图准确预测编译器会如何分配字段偏移量，因为这可能会随着时间和平台的变化而变化

• 3.4.2. 避免这些问题最简单的方法是在分配后将缓冲区清零，除非我们可以确保它们被完全覆盖，或者知道它们不会被泄露到信任边界之外

• 3.4.3. 即使你的代码本身并不使用敏感数据，但通过这种内存泄露路径也可能在进程中的任何位置将其他数据泄露出去

4. Heartbleed漏洞

4.1. Heartbleed是研究低级语言脆弱性的一个很好的对象

• 4.1.1. 小错误会引发巨大的影响

• 4.1.2. 如果恰好发生在内存中错误的位置上，则缓冲区溢出可能会暴露具有高价值的秘密

• 4.1.3. 设计（协议规范）中已经预测到了这个错误，指出代码应该忽略字节长度不正确的心跳请求，但在没有明确测试的情况下，没有人注意到这个漏洞

4.2. Heartbleed是TLS Heartbeat扩展中OpenSSL实践的一个缺陷，于2012年在RFC 6520中一起提出

4.3. Heartbleed漏洞不仅作为“第一个带有徽标的bug”而成为新闻，还在部署了流行的OpenSSL TLS库的服务器中揭示了一个微小的漏洞

4.4. 所谓心跳，就是往返交互心跳请求，其有效载荷是16至16384(214)字节之间的任意数据，与之对应的心跳响应中也携带了相同的载荷

4.5. 格式错误的心跳请求中会发生严重缺陷，这些请求提供了一个小的有效载荷，却声称是一个较大的载荷

4.6. 最终会被泄露的数据取决于内存分配的弱点，攻击者可以重复利用这个漏洞来访问服务器内存，并最终得到各种敏感数据

4.7. 对“会说谎”的心跳请求做出预测

• 4.7.1. 这些请求会要求比它们所提供的载荷多得多的载荷

4.8. 在格式正常的请求中，一切都可以完美地运行，只有格式错误的请求才会让本无恶意的代码出现问题

4.9. 心跳响应中泄露的服务器内存并不会对服务器造成直接伤害：只有对被泄露的大量数据进行仔细分析后，人们才能看出损失程度

• 4.9.1. 它不太可能发生，并且返回比接收到的载荷多得多的载荷数据，乍看起来似乎是无害的