为什么strlcpy和strlcat不安全？

#1 楼

首先，strlcpy从未被用作strncpy的安全版本（而strncpy从未被用作strcpy的安全版本）。这两个功能是完全无关的。 strncpy是一个完全与C字符串（即以null终止的字符串）无关的函数。它的名称中带有str...前缀的事实只是一个历史错误。 strncpy的历史和用途是众所周知的且有据可查。这是一个功能，用于处理在某些历史版本的Unix文件系统中使用的所谓的“固定宽度”字符串（不适用于C字符串）。如今，有些程序员对它的名称感到困惑，并认为strncpy某种程度上应该用作有限长度的C字符串复制功能（strcpy的“安全”同级），实际上这完全是胡说八道，并导致不良的编程习惯。当前形式的C标准库没有任何功能可用于有限长度的C字符串复制。这就是strlcpy所适合的地方。strlcpy确实是为使用C字符串而创建的真正的有限长度复制功能。 strlcpy正确执行了有限长度复制功能应做的所有事情。唯一可以针对的批评是遗憾的是，这不是标准。

其次，另一方面，strncat确实是一个可与C字符串一起使用并执行有限长度的串联的函数（它确实是strcat的“安全”同级）。为了正确使用此函数，程序员必须格外小心，因为此函数接受的size参数实际上并不是接收结果的缓冲区的大小，而是其剩余部分的大小（也包括终止符）被隐式计算）。这可能会造成混淆，因为为了将该大小与缓冲区的大小绑定在一起，程序员必须记住要执行一些额外的计算，这常常被用来批评strncat。 strlcat解决了这些问题，更改了接口，因此不需要额外的计算（至少在调用代码中）。同样，我看到的唯一可以批评这一点的依据是该功能不是标准的。同样，由于基于重新扫描的字符串串联的概念的可用性有限，因此在专业代码中，strcat组的功能很少出现。

关于这些功能如何导致安全问题……它们根本不可能。它们不会导致比C语言本身“导致安全问题”更大的程度的安全问题。您会看到，很长一段时间以来，人们一直强烈认为C ++语言必须朝着发展成某种怪异的Java风格的方向发展。这种情绪有时也会蔓延到C语言的领域，从而导致对C语言功能和C标准库的功能相当无知和被迫批评。我怀疑在这种情况下，我们可能也会处理类似的问题，尽管我当然希望事情并没有那么糟糕。

#2 楼

Ulrich的批评基于这样的想法，即程序未检测到的字符串截断会通过错误的逻辑导致安全问题。因此，为了安全起见，您需要检查截断。对字符串连接执行此操作意味着您正在执行以下检查：

if (destlen + sourcelen > dest_maxlen)
{
    /* Bug out */
}

现在，如果程序员记得的话，strlcat可以有效地执行此检查检查结果-因此可以安全地使用它：

if (strlcat(dest, source, dest_bufferlen) >= dest_bufferlen)
{
    /* Bug out */
}

Ulrich的要点是，因为必须要有destlen和sourcelen（或重新计算它们），所以strlcat确实有效），您最好还是使用效率更高的memcpy：

if (destlen + sourcelen > dest_maxlen)
{
    goto error_out;
}
memcpy(dest + destlen, source, sourcelen + 1);
destlen += sourcelen;

（在上面的代码中，dest_maxlen是可以被存储在dest中-比dest缓冲区的大小小一倍。dest_bufferlen是dest buffer的完整大小）。

#3 楼

当人们说“ strcpy()很危险，请改用strncpy()”（或类似的关于strcat()的声明等，但我将在这里使用strcpy()作为我的重点）时，它们表示strcpy()中没有边界检查。因此，字符串过长将导致缓冲区溢出。他们是正确的。在这种情况下使用strncpy()将防止缓冲区溢出。

我觉得strncpy()确实不能解决错误：它解决了一个好的程序员可以轻松避免的问题。

作为C程序员，您必须了解尝试复制字符串之前的目标大小。这也是strncpy()和strlcpy()的最后一个参数中的假设：您可以为它们提供该大小。复制字符串之前，您还可以知道源大小。然后，如果目的地不够大，请不要致电strcpy()。重新分配缓冲区或执行其他操作。

为什么我不喜欢strncpy()？




strncpy()在大多数情况下是一个不好的解决方案：您的字符串将被截断而不会发出任何通知-我宁愿自己编写额外的代码来弄清楚这一点，然后采取我想采取的行动，而不是让某个函数为我决定要做什么。

strncpy()效率很低。它写入目标缓冲区中的每个字节。您不需要目的地末尾的那几千个''strlcpy()''。
如果目的地不够大，它不会写一个终止的strncpy()。因此，无论如何您都必须这样做。这样做的复杂性不值得麻烦。

现在，我们来到strl*。从strncpy()所做的更改使它变得更好，但是我不确定*((char *)mempcpy(dst, src, n)) = 0;的特定行为是否可以保证它们的存在：它们过于具体。您仍然必须知道目标大小。它比strlcpy()更有效，因为它不一定要写入目标中的每个字节。但这解决了一个可以解决的问题：strlcat()。

我认为没有人说strncpy()或strlcpy()会导致安全问题，他们（和我）都在说他们可以例如，当您希望写入完整的字符串而不是字符串的一部分时，会导致错误。

这里的主要问题是：要复制多少字节？程序员必须知道这一点，如果他不知道，则strlcpy()或strlcat()不会救他。

strlcat()和q4312079q不是标准的，ISO C和POSIX都不是。因此，不可能在可移植程序中使用它们。实际上，q4312079q具有两个不同的变体：对于长度为0的边缘情况，Solaris实现与其他实现不同。这使得它的使用性比其他方面要小。

#4 楼

我认为Ulrich和其他人认为这会给人一种错误的安全感。意外地将字符串截断可能会对代码的其他部分产生安全影响（例如，如果文件系统路径被截断，则程序可能未在预期的文件上执行操作）。

#5 楼

有两个与使用strl函数有关的“问题”：


必须检查返回值
以避免被截断。

c1x标准草案作者和Drepper认为，程序员不会检查返回值。 Drepper说我们应该以某种方式知道长度并使用memcpy并完全避免使用字符串函数。标准委员会认为，除非_TRUNCATE标志另有说明，否则安全的strcpy应该在截断时返回非零值。这个想法是人们更可能使用if（strncpy_s（...））。


不能在非字符串上使用。

某些人认为即使馈入虚假数据，字符串函数也绝不会崩溃。这会影响标准功能，例如在正常情况下会断断续续的strlen。新标准将包括许多此类功能。当然，检查会降低性能。

建议的标准函数的缺点是，您可以知道strl函数会丢失多少数据。

#6 楼

我不认为strlcpy和strlcat是不安全的，或者至少这不是它们不包含在glibc中的原因-毕竟，glibc包含strncpy甚至strcpy。

他们的批评

根据Damien Miller的安全可移植性论文：


strlcpy和strlcat API正确检查了目标缓冲区的边界，
在所有情况下均以nul-terminate并返回源字符串的长度，
允许检测截断。该API已被大多数现代操作系统和许多独立软件包采用，包括OpenBSD（起源于此），Sun Solaris，FreeBSD，NetBSD，Linux内核，rsync和GNOME项目。值得注意的例外
是GNU标准C库glibc [12]，其维护者
坚决拒绝包括这些改进的API，将其标记为“非常低效的BSD废话” [4]，尽管大多数情况下，它们
更快的先验证据要比它们所取代的API更快[13]。结果，
OpenBSD端口树中存在的100多个软件包
维护着自己的strlcpy和/或strlcat替代品或等效的API。
这不是理想的状态。
/>

这就是为什么它们在glibc中不可用，但是在Linux上它们不可用并不是事实。它们在Linux的libbsd中可用：


https://libbsd.freedesktop.org/

它们被打包在Debian和Ubuntu和其他发行版中。您也可以只获取一份副本并在您的项目中使用-它是简短的并且在许可的许可下：


http://cvsweb.openbsd.org/cgi-bin/cvsweb/src /lib/libc/string/strlcpy.c?rev=1.11

#7 楼

安全性不是布尔值。 C函数并非完全“安全”或“不安全”，“安全”或“不安全”。如果使用不正确，C中的简单分配操作可能会“不安全”。当程序员提供正确使用的必要保证时，可以安全地（安全地）使用strlcpy（）和strlcat（），就像安全地使用strcpy（）和strcat（）一样。

要点所有这些C字符串函数，无论是标准的还是非标准的，都使它们易于使用安全级别。安全使用strcpy（）和strcat（）并非易事；多年来，C程序员将其弄错的次数证明了这一点，随之而来的是令人讨厌的漏洞和利用。 strlcpy（）和strlcat（）以及就此而言，安全使用strncpy（）和strncat（），strncpy_s（）和strncat_s（）有点容易，但是仍然很简单。他们不安全/不安全吗？如果使用不当，只不过是memcpy（）。