这个缓冲区溢出的后果？ [英] Consequences of this buffer overflow?

问题描述

因此，在这里，我认为我在查看其他人的代码时发现了一个小的缓冲区溢出问题。它立即使我感到不正确，并且有潜在危险，但我承认我无法解释这种错误的实际后果，如果有的话。

So here I believe I have a small buffer overflow problem I found when reviewing someone else's code. It immediately struck me as incorrect, and potentially dangerous, but admittedly I couldn't explain the ACTUAL consequences of this "mistake", if any.

我写了一个测试应用程序以演示该错误，但令我感到沮丧的是，无论溢出情况如何，它似乎都能正常运行。我想相信这只是偶然，但我希望得到一些反馈，以确定我的想法是否错误，或者这里是否确实存在问题，而这并没有在我的测试应用程序中显示出来。

I had written up a test app to demonstrate the error, but found (to my dismay) that it seems to run correctly regardless of the overflow. I want to believe that this is just by chance, but wanted some feedback to determine if my thinking were wrong, or if there truly is a problem here that just isn't showing its head in my test app.

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

The problem code (I think it is, anyway):

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个字符打印到缓冲区中，并导致缓冲区溢出。

Now, the reason this stood out to me and I want to flag it as a possible buffer overflow is because of the first strlen. Due to pointer arithmetic, the 'incorrect' placement of the + 1 will cause the strlen to return 26 instead of 27 (taking the length of "his string is 27 char long"). sprintf, I believe, then prints 27 char into the buffer and has caused a buffer overflow.

是正确的评估？

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

I wrote a test app to demonstrate this for the person who's code I was looking at, and found that even in the debugger the string will print correctly. I also attempting putting other variables on the stack and heap before and after this code to see if I could affect neighboring areas of memory, but was still receiving correct output. I realize that my newly allocated heap memory might not be adjacent, which would explain the lack of useful overflow, but I just really wanted to confirm with others' opinions if this is in fact an issue.

由于这是一个非常简单的问题，如果您也可以通过某种参考来支持您的回答，那就太好了。我很重视并欢迎您的意见，但我不会接受是的作为最终答案。

Since this is a pretty simple "question", it'd be nice if you could support your answer with some sort of reference as well. While I value and welcome your input, I'm not going to accept "yes it is" as the final answer. Thank you kindly in advance.

更新：许多很好的答案以及许多其他见解。不幸的是，我不能全部接受。感谢您分享您的知识并成为我的第二意见。感谢您的帮助。

Update: Many good answers with a lot of additional insight. Unfortunately, I can't accept them all. Thank you for sharing your knowledge and for being my 'second opinion'. I appreciate the help.

推荐答案

您的评估是正确的。
[edit]加上James Curran提到的更正。[/ edit]

Your assessment is correct. [edit] with the addition of the correction mentioned by James Curran.[/edit]

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

Likely, your test app didn't show the problem because the allocation is rounded up to the next multiple of 4, 8 or 16 (which are common allocation granularities).

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

This means you should be able to demonstrate with a 31 character long string.

或者，使用插入式本机内存探查器，该探查器可以将保护字节紧紧围绕这种分配。

Alternatively, use an "instrumenting" native memory profiler that can place guard bytes closely around such an allocation.

这篇关于这个缓冲区溢出的后果？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！