|
避免内部缓冲区溢出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 程序员必须十分警觉，并且有极强的安全意识，才能防止他们的程序出现问题，而且即使这些，使代码不出问题也不容易。 在现在，变量检查不会严重影响程序的效率。大多数应用程序不会注意到这点差异。所以，应该总是进行边界检查。在将数据复制到您自己的缓冲区之前，检查数据长度。同样，检查以确保不要将过大的数据传递给另一个库，因为您也不能相信其他人的代码！（回忆一下前面所讨论的内部缓冲区溢出。） 3其它危险是什么？遗憾的是，即使是系统调用的“安全”版本 ― 譬如，相对于strcpy()的strncpy()也不完全安全。也有可能把事情搞糟。即使安全的调用有时会留下未终止的字符串，或者会发生微妙的相差一位错误。当然，如果您偶然使用比源缓冲区小的结果缓冲区，则您可能发现自己处于非常困难的境地。与我们目前所讨论的相比，往往很难犯这些错误，但您应该仍然意识到它们。当使用这类调用时，要仔细考虑。如果不仔细留意缓冲区大小，包括bcopy()、fgets()、memcpy()、snprintf()、strccpy()、strcadd()、strncpy() 和 vsnprintf()，许多函数会行为失常。 另一个要避免的系统调用是 getenv()。使用getenv() 的最大问题是您从来不能假定特殊环境变量是任何特定长度的。我们将在后续的专栏文章中讨论环境变量带来的种种问题。 到目前为止，我们已经给出了一大堆常见 C 函数，这些函数容易引起缓冲区溢出问题。当然，还有许多函数有相同的问题。 特别是，注意第三方 COTS 软件。不要设想关于其他人软件行为的任何事情。还要意识到我们没有仔细检查每个平台上的每个常见库（我们不想做那一工作），并且还可能存在其它有问题的调用。 即使我们检查了每个常见库的各个地方，如果我们试图声称已经列出了将在任何时候遇到的所有问题，则您应该持非常非常怀疑的态度。我们只是想给您起一个头。其余全靠您了。 4静态和动态测试工具我们将在以后的专栏文章中更加详细地介绍一些脆弱性检测的工具，但现在值得一提的是两种已被证明能有效帮助找到和去除缓冲区溢出问题的扫描工具。这两个主要类别的分析工具是静态工具（考虑代码但永不运行）和动态工具（执行代码以确定行为）。可以使用一些静态工具来查找潜在的缓冲区溢出问题。很糟糕的是，没有一个工具对一般公众是可用的！许多工具做得一点也不比自动化 grep 命令多，可以运行它以找到源代码中每个有问题函数的实例。由于存在更好的技术，这仍然是高效的方式将几万行或几十万行的大程序缩减到只有数百个“潜在的问题”。（在以后的专栏文章中，将演示一个基于这种方法的、草草了事的扫描工具，并告诉您有关如何构建它的想法。） 较好的静态工具利用以某些方式表示的数据流信息来断定哪个变量会影响到其它哪个变量。用这种方法，可以丢弃来自基于 grep 的分析的某些“假肯定”。 David Wagner 在他的工作中已经实现了这样的方法（在“Learning the basics of buffer overflows”中描述；请参阅 参考资料），在 Reliable Software Technologies 的研究人员也已实现。当前，数据流相关方法的问题是它当前引入了假否定（即，它没有标志可能是真正问题的某些调用）。 第二类方法涉及动态分析的使用。动态工具通常把注意力放在代码运行时的情况，查找潜在的问题。一种已在实验室使用的方法是故障注入。这个想法是以这样一种方式来检测程序：对它进行实验，运行“假设”游戏，看它会发生什么。有一种故障注入工具 ― FIST（请参阅 参考资料）已被用来查找可能的缓冲区溢出脆弱性。 最终，动态和静态方法的某些组合将会给您的投资带来回报。但在确定最佳组合方面，仍然有许多工作要做。 5最后下面表格总结了一些编程构造，我们建议你小心使用或避免使用它们。如果要想代码健壮，最好有一定容错处理。函数 严重性 解决方案
gets最危险使用 fgets（buf, size, stdin）。这几乎总是一个大问题！
strcpy很危险改为使用 strncpy。
strcat很危险改为使用 strncat。
sprintf很危险改为使用 snprintf，或者使用精度说明符。
scanf很危险使用精度说明符，或自己进行解析。
sscanf很危险使用精度说明符，或自己进行解析。
fscanf很危险使用精度说明符，或自己进行解析。
vfscanf很危险使用精度说明符，或自己进行解析。
vsprintf很危险改为使用 vsnprintf，或者使用精度说明符。
vscanf很危险使用精度说明符，或自己进行解析。
vsscanf很危险使用精度说明符，或自己进行解析。
streadd很危险确保分配的目的地参数大小是源参数大小的四倍。
strecpy很危险确保分配的目的地参数大小是源参数大小的四倍。
strtrns危险手工检查来查看目的地大小是否至少与源字符串相等。
realpath很危险（或稍小，取决于实现）分配缓冲区大小为 MAXPATHLEN。同样，手工检查参数以确保输入参数不超过 MAXPATHLEN。
syslog很危险（或稍小，取决于实现）在将字符串输入传递给该函数之前，将所有字符串输入截成合理的大小。
getopt很危险（或稍小，取决于实现）在将字符串输入传递给该函数之前，将所有字符串输入截成合理的大小。
getopt_long很危险（或稍小，取决于实现）在将字符串输入传递给该函数之前，将所有字符串输入截成合理的大小。
getpass很危险（或稍小，取决于实现）在将字符串输入传递给该函数之前，将所有字符串输入截成合理的大小。
getchar中等危险如果在循环中使用该函数，确保检查缓冲区边界。
fgetc中等危险如果在循环中使用该函数，确保检查缓冲区边界。
read中等危险如果在循环中使用该函数，确保检查缓冲区边界。
bcopy中等危险如果在循环中使用该函数，确保检查缓冲区边界。
fgets低危险确保缓冲区大小与它所说的一样大。
memcpy低危险确保缓冲区大小与它所说的一样大。
snprintf低危险确保缓冲区大小与它所说的一样大。
strccpy低危险确保缓冲区大小与它所说的一样大。
strcadd低危险确保缓冲区大小与它所说的一样大。
strncpy低危险确保缓冲区大小与它所说的一样大。
getchar低危险确保缓冲区大小与它所说的一样大。
vsnprintf低危险确保缓冲区大小与它所说的一样大。
文章来源于网络，版权归原作者所有，如有侵权，请联系删除。
| 
楼主
标题置顶
标题高亮
