缓冲区溢出

今天又有点时间，花了大概4个小时不到翻译了这个大概3500字的文章，感觉自己阅读速度真的有待提高。虽说边翻译边看边理解吧，但还是不满意。得多练才行啊……
原文链接：Buffer_Overflow

相关安全文章

缓冲区溢出描述

查看OWASP上缓冲区溢出攻击的文章

如何避免缓冲区溢出漏洞

查看OWASP开发指南上的关于避免缓冲区溢出的文章

如何查看缓冲区溢出的代码

查看OWASP代码阅读指南删给的关于如何查看缓冲区溢出和栈溢出漏洞代码的文章

如何检测缓冲区溢出漏洞

查看OWASP测试指南上的关于检测缓冲区溢出漏洞的文章

概览

当程序尝试在一个缓冲区存放比这个缓冲区能容纳的数据多的数据时或一个程序尝试把数据存放在一个缓冲区的内存区的时候，就会存在缓冲区溢出行为。这种情况下，一个缓冲区就是一个用来容纳字符串，整形数组等任何数据的分配好的顺序的内存块。写入的数据超过了分配的内存块能容纳数据的边界，就会使程序崩溃或执行恶意的代码。

描述

缓冲区溢出可能是最著名的软件安全漏洞了。大多数软件开发者知道什么是缓冲区溢出漏洞，但缓冲区溢出攻击对遗留的和新开发的应用来说还是很普遍的。一部分问题是由于能引发缓冲区溢出的手段和种类很多，另一部分是由于开发者经常使用易错的技术去防止缓冲区溢出。

缓冲区溢出很难发现，即使发现了通常也非常难利用。尽管如此，攻击者们已经设法从陌生的产品和组件中识别缓冲区溢出漏洞。

在一个标准的缓冲区溢出利用中，攻击者向程序发送的数据储存在一个尺寸不足的堆栈/缓冲区中。这导致信息在调用栈被覆盖，包括函数的返回节点。这个（攻击者的）数据覆盖了返回节点的值导致当函数返回时，它传递了一个在攻击者发送的数据中的恶意代码。

即使这种类型的堆栈/缓冲区溢出仍然在一些平台和开发团队中很普遍，但还是存在很多不同的其他类型的缓冲区溢出漏洞，包括堆缓冲区溢出（Heap buffer overflow）和大小差异错误（Off-by-one Error）。其他著名的非常相似的缺陷如格式化字符串攻击（Format string attack）。有非常多的很棒讲述了很多缓冲区溢出攻击如何起作用的细节的书，包括《Building Secure Software》，《Writing Secure Code》，《The Shellcoder’s Handbook》.

在代码层面，缓冲区溢出漏洞通常违反程序员的假设。在C和C++钟很多内存操纵函数不会表现出边界检验，而且他们可以很轻易的越过给它们分配的缓冲区的边界。即使有界函数，比如strncpy()，使用不当也会导致漏洞。对内存的操作和对数据尺寸的错误估计，这两种原因结合起来就是导致大部分缓冲区溢出的根本原因。

经典的缓冲区溢出漏洞发生场所：

• 依赖外部数据控制行为
• 依赖目前执行的代码之外的数据的特性
• 程序太复杂以至于程序员不能准确的预测它的行为

缓冲区溢出和web应用

攻击者使用缓冲区溢出污染一个web应用的执行栈，通过发送精心制作的输入数据给web应用，之后攻击者可以诱导web应用执行任意的代码-直接有效的接管设备。

缓冲区溢出缺陷可以出现在静态和动态的web服务器和应用服务器上，当然web应用自身也会出现。缓冲区溢出也被发现在被广泛使用的或很知名的服务器产品，这也对这些产品的用户造成了很大的威胁。当一个web应用使用库时，比如使用图形库生成图像，这相当于把自己暴露给了潜在的缓冲区溢出攻击。

缓冲区溢出也可以被发现于自定义的web应用代码中，当然也有缺乏仔细审查的web应用中招。缓冲区溢出缺陷在自定义的web应用中被发现的相对较少，因为很少有黑客对他们感兴趣。通常对一个黑客来说，如果发现了一个自定义web应用，想要利用的源码细节或错误细节（相比于仅仅使这个应用崩溃来说）显著的少。

后果

分类：

• 可利用：缓冲区溢出通常导致崩溃。其他的攻击行为导致缺少利用的可能，包括在死循环中放置程序。
• 访问控制（指令处理）：缓冲区溢出通常可以执行任意的外部的缺少安全策略的程序的代码。
• 其他：当导致了任意代码执行，那通常也可以破坏任意其他的安全服务。

曝光时间

• 需求规格说明：可以选择不易受这类问题影响的语言。
• 设计：可以使用一些规避技术如安全字符串库或容器抽象化
• 实施：很多逻辑错误可以引起这种情况。而由于缺乏或误用规避技术而变得恶化。

环境影响

几乎所有已知的web服务器，应用服务器，web应用环境都是对缓冲区溢出易感的。当然也有例外，比如使用的语言免疫这类共计，如JAVA和python（当然编译器自己的缓冲区溢出漏洞除外）。

平台

语言：C,C++,Fortran, 汇编

操作平台：全部，尽管可能有部分可以部署防御方法，但取决于环境。

需求资源

任何

严重程度

非常高

利用可能性

高-非常高

如何确定是否存在漏洞

对于服务器产品和库来说，保持关注你是用的产品的最新漏洞报告。对于自定义的web应用软件，所有接受用户通过HTTP请求输入的代码必须被审查，以确定这段代码可以处理任意大的输入。

如何保护自己

保持关注你是用的web应用服务产品和其他你的网络基础设备的最新漏洞报告，并应用最新的补丁。定期地使用一个或多个可以识别缓冲区溢出漏洞的扫描器扫描你的web网站，web服务产品，自定义web应用。对你的自定义web应用代码，你需要审查所有的接受用户通过HTTP请求输入的代码，确信他们可以对所有的输入进行适当的长度检查。即使你的环境不是对这类大型输入攻击易感的也需要做，以免有没捕获的攻击导致拒绝服务或其他操作问题。

风险影响

待决定（TBD）

例子

例 1.a

下面的简单代码演示了简单的缓冲区溢出，像第一个方案一样的依赖外部数据控制自身行为的脚本经常引发缓冲区溢出漏洞。这段代码使用gets()函数去读任意规模的数据到栈缓冲区。因为这里没有限制读取数据规模的方法，这段代码的安全度依赖用户通常输入的数据长度低于BUFSIZE个字符。

     ...
    char buf[BUFSIZE]; 
    gets(buf);
    ...

例 1.b

这个例子展示了在C++中模仿像gets()这样的不安全行为是多么的简单，使用”>>”去读取char[]字符串。

    ...
    char buf[BUFSIZE]; 
    cin >> (buf);
    ...

例 2

这段代码也依赖用户输入去控制它自身的行为，但它添加了一个间接的等级，用来限制内存拷贝函数memcpy()。这个函数接受一个目标缓冲区和一个源缓冲区，然后从源向目标拷贝一定数量的字节的数据。源缓冲区的内容是被read()函数读取的，但使用了特定的数字去指定memcpy()拷贝的字节长度。

    ...
    char buf[64], in[MAX_SIZE];
    printf("Enter buffer contents:\n");
    read(0, in, MAX_SIZE-1);
    printf("Bytes to copy:\n");
    scanf("%d", &bytes);
    memcpy(buf, in, bytes);
    ...

注意：这类缓冲区溢出漏洞（程序读取数据然后信任数据中的值并在剩下的数据上做内存操作）已经转化为一些频在图片，音频和其他处理文件库的操作中频繁出现。

例 3

这个例子的第二个方案依赖的数据的性质没有证实。在这个例子中，一个命名为lccopy()的函数携带一个字符串参数然后返回一个将字符串中所有大写字母转换为小写字母的复制字符串。这个函数在它的输入处没有边界检验，因为它认为字符串通常小于BUFSIZE。如果攻击者绕过了检验并调用了lccopy()，或代码改变对str真是大小的假设，那么lccopy()将会溢出缓冲区并无界调用strcpy()。

    char *lccopy(const char *str) {
        char buf[BUFSIZE];
        char *p;

        strcpy(buf, str);
        for (p = buf; *p; p++) {
             if (isupper(*p)) {
                *p = tolower(*p);
            }
        }   
        return strdup(buf);
    }

例 4

下面的代码演示了第三个方案，即太复杂的代码行为不能被准确的预测。这段代码来自从著名的libPNG图像解码器，它被一个应用的宽数组使用，包括Mozilla和一些IE的版本。

这段代码似乎安全的执行了边界检验，因为他检查了它用来控制复制的数据量的函数png_crc_read()的变化长度的大小。然而，在它测试长度之前，该代码对png_ptr->mode进行检验，然后如果这个检验失败了，则发出警告但会继续处理。因为长度测试是在一个else if中，那么如果第一个if触发将不会触发else if，并且在调用png_crc_read()时盲目使用，这潜在的允许了堆栈溢出。

虽然这段代码在这个例子中没有那么复杂，但它展示了为什么要尽量减少在代码执行内存操作的时候的复杂性。

    if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
        /* Should be an error, but we can cope with it */
        png_warning(png_ptr, "Missing PLTE before tRNS");
    }
    else if (length > (png_uint_32)png_ptr->num_palette) {
        png_warning(png_ptr, "Incorrect tRNS chunk length");
        png_crc_finish(png_ptr, length);
        return;
    }
    ...
    png_crc_read(png_ptr, readbuf, (png_size_t)length);

例 5

这个例子也展示了第三个方案，代码太复杂以至于溢出。这个例子中，漏洞是由一个函数的模糊接口暴露的，而不是代码结构（前一个例子）。

getUserInfo()函数携带一个名为username的多字节字符串和一个指向用户信息的结构体，并使用用户信息填充。自从Windows使用username的Unicode作为用户验证，首先将username参数从从多字节字符串转化为Unicode字符串。之后这个函数不正确的传递了Unicode后的user的字节规模（相比于字符数规模）。对MultiByteToWideChar()的调用可能因此向unicodeUser数组写下(UNLEN+1)*sizeof(WCHAR)个符数，或者(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR)字节，但只分配了(UNLEN+1)*sizeof(WCHAR)字节。如果username字符串包含了比UNLEN个字符更多的字符，那么调用MultiByteToWideChar()将会造成unicodeUser缓冲区溢出。

    void getUserInfo(char *username, struct _USER_INFO_2 info){
        WCHAR unicodeUser[UNLEN+1];
        MultiByteToWideChar(CP_ACP, 0, username, -1,
                            unicodeUser, sizeof(unicodeUser));
    NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
    }

相关攻击

格式化字符串攻击

相关漏洞

堆缓冲区溢出

相关控制

类别：输入验证。

前期设计：使用能自动进行边界检测的语言或编译器。

设计：使用一个抽象库去抽象危险的APS，不是一个完整的解决方案。

通过建设预设计：基于编译器的金丝雀机制，如StackGuard, ProPolice和Microsoft Visual Studio / GS等，除非它提供自动的边界检验，否则不是一个完整的解决方案。

操作：使用操作系统级预防，不是一个完整的解决方案。

development 开发

review 查看

attempt 尝试

sequential 顺序的

memory 内存

bounds 界限

block 块

allocate 分配

array 数组

malicious 恶意的

legacy 遗产，遗留

error-prone 易错的

prevent 防止

Nevertheless 尽管如此

manage to 设法

call stack 调用栈

flaw 缺陷

violantion 违反

assumption 假设

manipulation 操纵

bounded functions 有界函数

corrupt 污染，腐败

crafted 精心制作的

arbitrary 任意的

pose 造成

library 库

custom 自定义的

instruction 指令

subvert 颠覆，破坏

susceptible 易感的

interpretor 编译器

immune 免疫

deploy 部署

patches 补丁

Periodically 定期地

appears 似乎

ambiguous 模棱两可的

argument 参数