C中大多数缓冲区溢出问题可以直接追溯到标准 C 库。最有害的罪魁祸首是不进行自变量检查的、有问题的字符串操作strcpy、strcat、sprintf 和 gets。

大部分程序员仍然会使用这些函数，因为从来没有人教开发人员避免使用它们。某些人从各处获得某个提示，但即使是优秀的开发人员也会被这弄糟，下面就来分析一下。

第一位公共的“敌人”是 gets()。建议不要使用 gets()。该函数从标准输入读入用户输入的一行文本，它在遇到 EOF字符或换行字符之前，不会停止读入文本。也就是：gets() 根本不执行边界检查。因此，使用 gets()总是有可能使任何缓冲区溢出。作为一个替代方法，可以使用 fgets()。它可以做与 gets()所做的同样的事情，但它接受用来限制读入字符数目的大小参数，因此，提供了一种防止缓冲区溢出的方法。例如，不要使用以下代码：

void main(){ char buf[1024]; gets(buf);}

而使用以下代码：

#define BUFSIZE 1024void main(){ char buf[BUFSIZE]; fgets(buf, BUFSIZE, stdin);}

C 编程中的主要陷阱C语言中一些标准函数很有可能使你陷入困境。但不是所有函数使用都不好。通常，利用这些函数之一需要任意输入传递给该函数。这个列表包括：

strcpy()

strcat()

sprintf()

scanf()

sscanf()

fscanf()

vfscanf()

vsprintf

vscanf()

vsscanf()

streadd()

strecpy()

strtrns()

我们推荐使用，如果有可能，应尽量避免使用这些函数。这些函数在大多数情况下，都有合理的替代方法。我们将仔细检查它们中的每一个，所以可以看到什么构成了它们的误用，以及如何避免它。

strcpy()函数将源字符串复制到缓冲区。没有指定要复制字符的具体数目。复制字符的数目直接取决于源字符串中的数目。如果源字符串碰巧来自用户输入，且没有专门限制其大小，则有可能会陷入大的麻烦中!

如果知道目的地缓冲区的大小，则可以添加明确的检查：

if(strlen(src) >= dst_size){ /* Do something appropriate, such as throw an error. */}else{ strcpy(dst, src);}

完成同样目的的更容易方式是使用 strncpy() 库例程：

strncpy(dst, src, dst_size-1);dst[dst_size-1] = '\0'; /* Always do this to be safe! */

如果 src 比 dst 大，则该函数不会抛出一个错误;当达到最大尺寸时，它只是停止复制字符。注意上面调用 strncpy()中的 -1。如果 src 比 dst 长，则那给我们留有空间，将一个空字符放在 dst 数组的末尾。

当然，可能使用strcpy()不会带来任何潜在的安全性问题，正如在以下示例中所见：

strcpy(buf, "Hello!");

即使这个操作造成 buf 的溢出，但它只是对几个字符这样而已。由于我们静态地知道那些字符是什么，并且很明显，由于没有危害，所以这里无须担心 ― 当然，除非可以用其它方式覆盖字符串Hello所在的静态存储器。

确保strcpy()不会溢出的另一种方式是，在需要它时就分配空间，确保通过在源字符串上调用 strlen() 来分配足够的空间。例如：

dst = (char *)malloc(strlen(src));strcpy(dst, src);

strcat()函数非常类似于strcpy()，除了它可以将一个字符串合并到缓冲区末尾。它也有一个类似的、更安全的替代方法strncat()。如果可能，使用strncat()而不要使用strcat()。

函数sprintf()和vsprintf()是用来格式化文本和将其存入缓冲区的通用函数。它们可以用直接的方式模仿strcpy()行为。换句话说，使用sprintf()和vsprintf()与使用strcpy()一样，都很容易对程序造成缓冲区溢出。例如，考虑以下代码：

void main(int argc, char **argv){ char usage[1024]; sprintf(usage, "USAGE: %s -f flag [arg1]\n", argv[0]);}

我们经常会看到类似上面的代码。它看起来没有什么危害。它创建一个知道如何调用该程序字符串。那样，可以更改二进制的名称，该程序的输出将自动反映这个更改。虽然如此, 该代码有严重的问题。文件系统倾向于将任何文件的名称限制于特定数目的字符。那么，您应该认为如果您的缓冲区足够大，可以处理可能的最长名称，您的程序会安全，对吗?只要将1024改为对我们的操作系统适合的任何数目，就好了吗?但是，不是这样的。通过编写我们自己的小程序来推翻上面所说的，可能容易地推翻这个限制：

void main(){ execl("/path/to/above/program", <<insert really long string here>>, NULL);}

函数execl()启动第一个参数中命名的程序。第二个参数作为argv[0]传递给被调用的程序。我们可以使那个字符串要多长有多长!

那么如何解决sprintf()带来得问题呢?遗憾的是，没有完全可移植的方法。某些体系结构提供了snprintf()方法，即允许程序员指定将多少字符从每个源复制到缓冲区中。例如，如果我们的系统上有snprintf，则可以修正一个示例成为：

void main(int argc, char **argv){ char usage[1024]; char format_string = "USAGE: %s -f flag [arg1]\n"; snprintf(usage, format_string, argv[0],1024-strlen(format_string) + 1);}

注意，在第四个变量之前，snprintf()与sprintf()是一样的。第四个变量指定了从第三个变量中应被复制到缓冲区的字符最大数目。注意，1024 是错误的数目!我们必须确保要复制到缓冲区使用的字符串总长不超过缓冲区的大小。所以，必须考虑一个空字符，加上所有格式字符串中的这些字符，再减去格式说明符 %s。该数字结果为1000,但上面的代码是更具有可维护性，因为如果格式字符串偶然发生变化，它不会出错。

sprintf()的许多(但不是全部)版本带有使用这两个函数的更安全的方法。可以指定格式字符串本身每个自变量的精度。例如，另一种修正上面有问题的sprintf()的方法是：

void main(int argc, char **argv){ char usage[1024]; sprintf(usage, "USAGE: %.1000s -f flag [arg1]\n", argv[0]);}

注意，百分号后与 s 前的 .1000。该语法表明，从相关变量(本例中是 argv[0])复制的字符不超过 1000 个。

如果任一解决方案在您的程序必须运行的系统上行不通，则最佳的解决方案是将snprintf()的工作版本与您的代码放置在一个包中。可以找到以sh归档格式的、自由使用的版本;请参阅 参考资料。

继续，scanf系列的函数也设计得很差。在这种情况下，目的地缓冲区会发生溢出。考虑以下代码：

void main(int argc, char **argv){ char buf[256]; sscanf(argv[0], "%s", &buf);}

如果输入的字大于 buf 的大小，则有溢出的情况。幸运的是，有一种简便的方法可以解决这个问题。考虑以下代码，它没有安全性方面的薄弱环节：

void main(int argc, char **argv){ char buf[256]; sscanf(argv[0], "%255s", &buf);}

百分号和 s 之间的 255 指定了实际存储在变量 buf 中来自 argv[0] 的字符不会超过 255 个。其余匹配的字符将不会被复制。

接下来，我们讨论streadd()和strecpy()。由于，不是每台机器开始就有这些调用，那些有这些函数的程序员，在使用它们时，应该小心。这些函数可以将那些含有不可读字符的字符串转换成可打印的表示。例如，考虑以下程序：

#include <libgen.h>void main(int argc, char **argv){ char buf[20]; streadd(buf, "\t\n", ""); printf(%s\n", buf);}

该程序打印：

\t\n

而不是打印所有空白。如果程序员没有预料到需要多大的输出缓冲区来处理输入缓冲区(不发生缓冲区溢出)，则streadd() 和 strecpy()函数可能有问题。如果输入缓冲区包含单一字符 ― 假设是 ASCII 001(control-A)―则它将打印成四个字符\001。这是字符串增长的最坏情况。如果没有分配足够的空间，以至于输出缓冲区的大小总是输入缓冲区大小的四倍，则可能发生缓冲区溢出。

另一个较少使用的函数是strtrns()，因为许多机器上没有该函数。函数strtrns()取三个字符串和结果字符串应该放在其内的一个缓冲区，作为其自变量。第一个字符串必须复制到该缓冲区。一个字符被从第一个字符串中复制到缓冲区，除非那个字符出现在第二个字符串中。如果出现的话，那么会替换掉第三个字符串中同一索引中的字符。这听上去有点令人迷惑。让我们看一下，将所有小写字符转换成大写字符的示例：

#include <libgen.h>void main(int argc, char **argv){ char lower[] = "abcdefghijklmnopqrstuvwxyz"; char upper[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; char *buf; if(argc < 2) { printf("USAGE: %s arg\n", argv[0]); exit(0); } buf = (char *)malloc(strlen(argv[1])); strtrns(argv[1], lower, upper, buf); printf("%s\n", buf);}

以上代码实际上不包含缓冲区溢出。但如果我们使用了固定大小的静态缓冲区，而不是用malloc()分配足够空间来复制argv[1]，则可能会引起缓冲区溢出情况。

避免内部缓冲区溢出realpath()函数接受可能包含相对路径的字符串，并将它转换成指同一文件的字符串，但是通过绝对路径。在做这件事时，它展开了所有符号链接。

该函数取两个自变量，第一个作为要规范化的字符串，第二个作为将存储结果的缓冲区。当然，需要确保结果缓冲区足够大，以处理任何大小的路径。分配的MAXPATHLEN缓冲区应该足够大。然而，使用realpath()有另一个问题。如果传递给它的、要规范化的路径大小大于MAXPATHLEN，则realpath()实现内部的静态缓冲区会溢出!虽然实际上没有访问溢出的缓冲区，但无论如何它会伤害您的。结果是，应该明确不使用realpath()，除非确保检查您试图规范化的路径长度不超过MAXPATHLEN。

其它广泛可用的调用也有类似的问题。经常使用的syslog()调用也有类似的问题，直到不久前，才注意到这个问题并修正了它。大多数机器上已经纠正了这个问题，但您不应该依赖正确的行为。最好总是假定代码正运行在可能最不友好的环境中，只是万一在哪天它真的这样。getopt()系列调用的各种实现，以及getpass()函数，都可能产生内部静态缓冲区溢出问题。如果您不得不使用这些函数，最佳解决方案是设置传递给这些函数的输入长度的阈值。

自己模拟gets()的安全性问题以及所有问题是非常容易的。例如，下面这段代码：

char buf[1024];int i = 0;char ch;while((ch = getchar()) != '\n'){ if(ch == -1) break; buf[i++] = ch;}

哎呀!可以用来读入字符的任何函数都存在这个问题，包括getchar()、fgetc()、getc() 和 read()。

缓冲区溢出问题的准则是：总是确保做边界检查。

C 和 C++ 不能够自动地做边界检查，这实在不好，但确实有很好的原因，来解释不这样做的理由。边界检查的代价是效率。一般来讲，C 在大多数情况下注重效率。然而，获得效率的代价是，C 程序员必须十分警觉，并且有极强的安全意识，才能防止他们的程序出现问题，而且即使这些，使代码不出问题也不容易。

在现在，变量检查不会严重影响程序的效率。大多数应用程序不会注意到这点差异。所以，应该总是进行边界检查。在将数据复制到您自己的缓冲区之前，检查数据长度。同样，检查以确保不要将过大的数据传递给另一个库，因为您也不能相信其他人的代码!(回忆一下前面所讨论的内部缓冲区溢出。)

其它危险是什么?遗憾的是，即使是系统调用的“安全”版本 ― 譬如，相对于strcpy()的strncpy()也不完全安全。也有可能把事情搞糟。即使安全的调用有时会留下未终止的字符串，或者会发生微妙的相差一位错误。当然，如果您偶然使用比源缓冲区小的结果缓冲区，则您可能发现自己处于非常困难的境地。

与我们目前所讨论的相比，往往很难犯这些错误，但您应该仍然意识到它们。当使用这类调用时，要仔细考虑。如果不仔细留意缓冲区大小，包括bcopy()、fgets()、memcpy()、snprintf()、strccpy()、strcadd()、strncpy() 和 vsnprintf()，许多函数会行为失常。

另一个要避免的系统调用是 getenv()。使用getenv() 的最大问题是您从来不能假定特殊环境变量是任何特定长度的。我们将在后续的专栏文章中讨论环境变量带来的种种问题。

到目前为止，我们已经给出了一大堆常见 C 函数，这些函数容易引起缓冲区溢出问题。当然，还有许多函数有相同的问题。特别是，注意第三方 COTS 软件。不要设想关于其他人软件行为的任何事情。还要意识到我们没有仔细检查每个平台上的每个常见库(我们不想做那一工作)，并且还可能存在其它有问题的调用。

即使我们检查了每个常见库的各个地方，如果我们试图声称已经列出了将在任何时候遇到的所有问题，则您应该持非常非常怀疑的态度。我们只是想给您起一个头。其余全靠您了。

版权声明：转载文章来自公开网络，版权归作者本人所有，推送文章除非无法确认，我们都会注明作者和来源。如果出处有误或侵犯到原作者权益，请与我们联系删除或授权事宜。