缓冲区溢出的后果是什么？

Question

所以在这里我相信我在审查别人的代码时发现了一个小的缓冲区溢出问题。我立即觉得这是不正确的，而且有潜在的危险，但不可否认的是，我无法解释这个“错误”的实际后果（如果有的话）。

我编写了一个测试应用程序来演示该错误，但发现（令我沮丧的是）无论溢出如何，它似乎都能正确运行。我想相信这只是偶然，但需要一些反馈来确定我的想法是否错误，或者这里是否确实存在问题而没有在我的测试应用程序中显现出来。

问题代码（无论如何，我认为是这样）：

char* buffer = new char[strlen("This string is 27 char long" + 1)];
sprintf(buffer, "This string is 27 char long");

现在，这对我来说很突出并且我想将其标记为可能的缓冲区溢出的原因是因为第一个 strlen。由于指针算术，+ 1 的“不正确”放置将导致 strlen 返回 26 而不是 27 （取“他的字符串长度为 27 个字符”的长度）。 sprintf，我相信，然后将 27 个字符打印到缓冲区中并导致缓冲区溢出。

这是正确的评估吗？

我编写了一个测试应用程序来向我正在查看的代码的人演示这一点，并发现即使在调试器中，字符串也会正确打印。我还尝试在此代码之前和之后将其他变量放入堆栈和堆上，看看是否会影响相邻的内存区域，但仍然收到正确的输出。我意识到我新分配的堆内存可能不相邻，这可以解释缺乏有用的溢出，但我真的想确认其他人的意见，如果这实际上是一个问题。

由于这是一个非常简单的“问题”，因此如果您也能通过某种参考来支持您的答案，那就太好了。虽然我重视并欢迎您的意见，但我不会接受“是的”作为最终答案。预先感谢您。

---

更新：许多很好的答案，还有很多额外的见解。不幸的是，我无法全部接受。感谢您分享您的知识并成为我的“第二意见”。我很感激你的帮助。

Answer 1

你的评价是正确的。
[编辑]加上 James Curran 提到的修正。[/编辑]

很可能，您的测试应用程序没有显示问题，因为分配被四舍五入到 4、8 或 16 的下一个倍数（这是常见的分配）粒度）。

这意味着您应该能够使用 31 个字符长的字符串进行演示。

或者，使用“检测”本机内存分析器，该分析器可以将保护字节紧密地放置在此类分配周围。

Answer 2

您的评估是正确的，除了 springf 会在缓冲区中放入 28 个字符，计算末尾的字符串结尾 NUL （这就是为什么您首先需要放错位置的“+1”）

请注意，根据我的经验，如果有些东西在调试器之外失败了，但可以在调试器中单步执行，在 100% 的情况下，您已经超出了本地缓冲区。调试器将更多内容推送到堆栈上，因此重要的内容不太可能被覆盖。

Answer 3

问题是你正在内存中的某个地方写入，而不是在堆栈上。
因此，很难真正看出问题所在。
如果您想查看损坏情况，请尝试在堆栈上分配字符串

char buffer[strlen("This string is 27 char long" + 1)];

并写入它。
其他变量将被写入，如果您确实知道二进制文件是如何工作的，您还可以添加一些要执行的代码。

要利用这样的缓冲区溢出，您需要写入所需的数据，然后找到一种方法“跳转”到要执行的数据。

Answer 4

是的，你是对的。分配的缓冲区将小 2 个字节，无法容纳该字符串。

由于这是在堆上分配的，因此可能会导致堆损坏。然而，这种情况的可能性取决于在此之前发生的其他内存分配和释放以及所使用的堆管理器。有关详细信息，请参阅堆溢出。

Answer 5

许多历史上的malloc实现将簿记数据紧接在分配的块之前和/或之后。您可能会覆盖此类数据，在这种情况下，您不会看到任何错误/崩溃，直到您尝试释放内存（或者可能释放下一个块发生的任何内容）。同样，后续分配的簿记信息也可能会覆盖您的字符串。

我怀疑现代的 malloc 实现通过用完整性检查数据填充分配来努力防止堆损坏，所以如果你幸运的话，不会发生任何不好的事情，或者你可能会在稍后收到警告消息分配/自由操作。

Answer 6

您是正确的，本例中的指针算术会产生传递给 new 的不正确（较短）的长度。无法发生此崩溃的最可能原因是内存分配实际提供了多少缓冲区空间存在一些不确定性。

允许库提供比请求更大的缓冲区。此外，缓冲区后面的任何内容也可能以受机器字对齐规则约束的分配标头为前缀。这意味着在下一个分配标头之前最多可以有三个填充字节（取决于平台）。

即使您覆盖了下一个分配标头（用于管理分配的内存块），在下一个块的所有者尝试将其返回到堆之前，它也不会表现为问题。

Answer 7

我尝试使用堆分配，在这种情况下变量在内存中不是连续的。这就是为什么在这种情况下很难发生缓冲区溢出。

购买并尝试使用堆栈溢出，

#include "stdio.h"
#include "string.h"

int main()
{
     unsigned int  y      = (0xFFFFFFFF);
     char buffer[strlen("This string is 27 char long" + 1)];
      unsigned int  x      = (0xFFFFFFFF);
      sprintf(buffer, "This string is 27 char long");

      printf("X (%#x) is %#x, Y (%#x) is %#x, buffer '%s' (%#x) \n", &x, x,&y, y, buffer, buffer);
      return 0;
  }

您将看到 Y 已损坏。

Answer 8

正如其他人所说，您认为这不好是完全正确的，而您没有看到这一点的原因是填充。尝试valgrind，这应该能明确地找到该错误。

Answer 9

你真正的问题是你正在写

char* buffer = new char[strlen("This string is 27 char long" + 1)];

而不是

char* buffer = new char[strlen("This string is 27 char long") + 1];

意味着在第一个你给 strlen() 一个不是字符串开头的地址。

试试这个代码：

const char szText[] = "This string is 27 char long";
char* buffer = new char[strlen(szText) + 1];
sprintf(buffer, szText);

Answer 10

字符串在调试器中打印良好的原因是，作为 sprintf 的一部分，尾随 NULL 字符被写入内存（在本例中超出您分配的缓冲区），并且在读取字符串时出现 NULL 字符按预期终止字符串。

问题是包含 NULL 字符的字节尚未作为原始 new 的一部分进行分配，因此稍后可用于不同的分配。在这种情况下，当您随后读取该字符串时，您可能会得到附加了垃圾的原始字符串。

Answer 11

正确的说法。由于您将字符串的第二个字符的地址传递给 strlen()，因此您得到的长度会少一个字符。除此之外，主要问题是 sprintf()，这是它不安全的原因之一。

即使这样也能编译并执行（也可能崩溃）。

    char* x = new char;
    sprintf(x, "This is way longer than one character");
    printf("%s", x);

为了避免这个危险问题，您应该使用此函数的安全版本，例如 GCC 下的 snprintf() 或 asprintf() 或 MSVC 下的 sprintf_s()。

作为参考，请查看 GNU这方面的 C 库文档以及 MSDN 的 sprintf() 文章的安全说明。