越界访问数组有多危险？

#1 楼

就ISO C标准（语言的官方定义）而言，访问其边界之外的数组具有“未定义的行为”。其字面意思是：


使用非便携式或错误程序构造或错误数据
的行为，而本国际标准不对此施加任何强制性
要求


对此进行了非规范性注释：


可能的不确定行为包括完全忽略情况以产生无法预测的结果，在翻译或程序执行过程中以
环境的特征记录的方式运行（无论是否发出诊断消息），以
终止翻译或执行（发布时）的诊断消息）。


这就是理论。现实是什么？

在“最佳”情况下，您将访问一些内存，这些内存要么是当前正在运行的程序所拥有的（这可能导致您的程序行为不当），要么不是您当前正在运行的程序（这可能会导致您的程序因分段错误而崩溃）。或者，您可能尝试写入程序所拥有的内存，但是将其标记为只读；这可能还会导致您的程序崩溃。

假设您的程序在试图保护同时运行的进程彼此之间的操作系统下运行。如果您的代码在“裸机”上运行，比如说它是OS内核或嵌入式系统的一部分，则没有这种保护；您行为不当的代码就是应该提供这种保护的内容。在这种情况下，损坏的可能性会更大，包括在某些情况下对硬件（或附近的东西或人）的物理损坏。

即使在受保护的OS环境中，保护也不总是100％。例如，存在一些操作系统错误，这些错误允许未经特权的程序获得根（管理）访问权限。即使具有普通用户特权，出现故障的程序也可能消耗过多的资源（CPU，内存，磁盘），从而可能使整个系统瘫痪。许多恶意软件（病毒等）利用缓冲区溢出来获得对系统的未授权访问。

（一个历史示例：我听说在某些具有核心内存的旧系统上，反复访问一个紧密的循环中的单个内存位置实际上可能导致该内存块融化；其他可能性包括破坏CRT显示屏，并以驱动器柜的谐波频率移动磁盘驱动器的读/写磁头，从而导致其穿越天台掉下来。）

总是有天网担心。

最重要的是：如果您可以编写程序来故意做一些不好的事情，至少从理论上讲，一个bug程序有可能意外地做同样的事情。

在实践中，运行在MacOS X系统上的bug程序不可能做比崩溃更严重的事情。但是不可能完全防止错误的代码做真正的坏事。

#2 楼

通常，当今的操作系统（无论如何还是流行的操作系统）都使用虚拟内存管理器在受保护的内存区域中运行所有应用程序。事实证明，简单地读写在已分配/分配给您的进程的区域之外的REAL空间中存在的位置并不是很容易的事情。

直接答案：

1）读取几乎永远不会直接破坏另一个进程，但是，如果您碰巧读取用于加密，解密或验证程序/进程的KEY值，则读取可能会间接破坏进程。如果您根据所读取的数据做出决定，则超出范围的读取可能会对您的代码产生一些不利/意想不到的影响

2）只有这样，您才能通过写入可访问的位置来真正破坏某些东西如果您要写入的内存地址实际上是硬件寄存器（实际上不是用于数据存储而是用于控制某些硬件的位置），而不是RAM位置，则表示内存地址。实际上，除非您编写的是一次性不可写的可编程位置（或类似性质的东西），否则您仍然通常不会损坏某些东西。

3）通常在调试器内部运行调试模式下的代码。当您执行了一些被认为不可行或彻头彻尾的非法操作时，在调试模式下运行确实会使TEND（但并非总是）更快地停止代码。

4）切勿使用宏，使用已具有数组的数据结构内置索引范围检查等。...

ADDITIONAL
我应该补充一点，以上信息实际上仅适用于使用带有内存保护窗口的操作系统的系统。如果为嵌入式系统或什至使用没有内存保护窗口（或虚拟寻址窗口）的操作系统（实时或其他）的系统编写代码，则在读写内存时应多加注意。同样在这种情况下，应始终采用SAFE和SECURE编码做法，以避免安全问题。

#3 楼

不检查边界会导致难看的副作用，包括安全漏洞。丑陋的事情之一是任意代码执行。在经典示例中：如果您有一个固定大小的数组，并使用strcpy()在此处放置用户提供的字符串，则用户可以给您一个字符串，该字符串使缓冲区溢出并覆盖其他内存位置，包括当您的计算机返回时应返回的代码地址函数完成。

这意味着您的用户可以向您发送一个字符串，该字符串将导致您的程序实质上调用exec("/bin/sh")，这会将其转换为Shell，执行他在系统上执行的所有操作，包括收集所有数据并将您的机器变成僵尸网络节点。

有关如何做到这一点的详细信息，请参见粉碎堆栈以获取乐趣和收益。

#4 楼

您写道：


我读到很多'可能发生的事情'，'分段可能是
最不严重的问题'，'您的硬盘可能变成粉红色而独角兽可能
在窗户下唱歌”，这一切都很好，但真正的危险是什么？


让我们这样说：装上枪。将其指向窗户外，没有任何特定目标和火力。有什么危险？

问题是您不知道。如果您的代码覆盖了使您的程序崩溃的内容，那么您会很好，因为它将使程序停止进入已定义状态。但是，如果它没有崩溃，则问题开始出现。哪些资源受程序控制，它可能对它们做什么？哪些资源可能会受到您程序的控制，它可能会对它们做什么？我知道至少有一个主要问题是由这种溢出引起的。问题出在看似毫无意义的统计功能中，该功能弄乱了生产数据库的一些不相关的转换表。结果是随后进行了一些非常昂贵的清理。实际上，如果此问题格式化了硬盘，则本来便宜很多，也更容易处理……换句话说，粉红色独角兽可能是您遇到的最小问题。

您的操作系统将保护你是乐观的。如果可能，请尝试避免超出范围。

#5 楼

不以root用户或任何其他特权用户身份运行程序不会损害您的系统，因此通常这是个好主意。

通过将数据写入某个随机内存位置，您不会直接当每个进程在其自己的内存空间中运行时，“破坏”计算机上运行的任何其他程序。

如果尝试访问未分配给进程的任何内存，操作系统将停止您的程序的执行分段错误。

因此，直接（无需以root用户身份运行和直接访问/ dev / mem之类的文件）就不会存在程序干扰操作系统上运行的任何其他程序的危险。 />
尽管如此-也许这是您在危险方面所听到的-意外地将随机数据盲目地写入随机存储器中，您肯定会损坏任何可能损坏的东西。

例如，您的程序可能想要删除由存储在程序中某个位置的文件名指定的特定文件。如果不经意间只是覆盖了文件名的存储位置，则可以删除一个完全不同的文件。

#6 楼

在Objective-C中为NSArray分配了特定的内存块。超出数组的界限意味着您将访问未分配给数组的内存。这意味着：


该内存可以具有任何值。无法根据您的数据类型知道数据是否有效。
此内存可能包含敏感信息，例如私钥或其他用户凭据。
该内存地址可能无效或受保护。
/>内存的值可能会发生变化，因为它正在被另一个程序或线程访问。
其他东西会使用内存地址空间，例如内存映射的端口。
将数据写入未知的内存地址可能会导致崩溃

从程序的角度来看，您总是想知道代码何时超出数组的范围。这可能导致返回未知值，从而导致您的应用程序崩溃或提供无效数据。

#7 楼

您可能需要在测试代码时尝试使用Valgrind中的memcheck工具-它不会捕获堆栈框架内单个数组边界冲突，但是它应该可以捕获许多其他类型的内存问题，包括那些可能导致细微的内存问题，单个功能范围以外的其他问题。
从手册：

Memcheck是一种内存错误检测器。它可以检测到C和C ++程序中常见的以下问题。

访问您不应该访问的内存，例如
使用未定义的值，即未初始化的值或从其他未定义的值派生的值。 />不正确的释放堆内存，例如两次释放堆块，或者不正确使用malloc / new / new []与free / delete / delete []
在memcpy和相关函数中重叠src和dst指针。
内存泄漏。


ETA：尽管，正如Kaz的回答所说，它不是灵丹妙药，也不总是提供最有用的输出，尤其是当您使用时令人兴奋的访问模式。

#8 楼

如果您曾经做过系统级编程或嵌入式系统编程，那么如果您写入随机存储器位置，可能会发生非常糟糕的事情。较早的系统和许多微控制器都使用内存映射的IO，因此写入映射到外设寄存器的内存位置可能会造成严重破坏，特别是如果异步完成。

一个示例是对闪存进行编程。通过将特定的值序列写入芯片地址范围内的特定位置，可以启用存储芯片上的编程模式。如果在此过程中另一过程要写入芯片中的任何其他位置，则将导致编程周期失败。

在某些情况下，硬件会将地址换行（最高有效位/地址字节将被忽略），因此写入超出物理地址空间末尾的地址实际上将导致数据被写入中间事物。

最后，像MC68000这样的旧式CPU可以锁定到只有硬件重置才能使它们重新运行的程度。几十年来没有对它们进行任何操作，但是我相信这是在尝试处理异常时遇到总线错误（不存在的内存）的情况，它只会暂停直到硬件复位被断言为止。

我最大的建议是为产品提供公然的插件，但我对此没有任何个人兴趣，并且我与它没有任何关系-而是基于数十年的C编程和嵌入式系统，其中可靠性至关重要，Gimpel的PC Lint不仅会检测到此类错误，而且还会不断地向您宣传不良习惯，从而使您成为一个更好的C / C ++程序员。

如果您可以从某人那里获取副本，我还建议您阅读MISRA C编码标准。我最近没看过任何东西，但是在过去，他们很好地解释了为什么/不应该做他们报道的事情。

Dunno关于您，但是大约第二或第三次我从任何应用程序中获得核心转储或挂断时，我对生产该产品的任何公司的看法下降了一半。第4或第5次，无论包装是什么，都变成了架子餐具，我用木桩穿过包装/光盘的中心，以确保它永远不会再次困扰我。

#9 楼

我正在与用于DSP芯片的编译器一起工作，该编译器有意生成从C代码中访问数组末尾的代码，而C代码则不会！

这是因为循环的结构使得迭代结束时为下一次迭代预取一些数据。因此，在最后一次迭代结束时预取的数据实际上从未被使用过。

这样的C代码的编写会调用未定义的行为，但这只是来自标准文档的形式，该文档本身具有最大的可移植性。

更常见的是，不能巧妙地优化访问范围的程序。这简直是​​越野车。该代码获取一些垃圾值，并且与上述编译器的优化循环不同，该代码随后在后续计算中使用该值，从而破坏了主题。

值得捕获这样的错误，因此值得仅出于这种原因就使行为无法定义：这样，运行时就可以生成诊断消息，例如“ main.c第42行中的数组溢出”。

在具有虚拟内存的系统上，可能恰好分配了一个数组，使得其后的地址位于虚拟内存的未映射区域中。然后访问将轰炸程序。



另外，请注意，在C语言中，我们允许创建一个指针，该指针位于数组末尾。而且此指针必须比指向数组内部的任何指针都更大。
这意味着C实现无法将数组直接放在内存末尾，在内存末尾，一个加号将环绕并看起来小于数组中的其他地址。


但是，即使未最大程度地移植，访问未初始化或超出范围的值有时仍是一种有效的优化技术。例如，这就是为什么Valgrind工具不会在未初始化的数据发生访问时报告该访问，而是仅在以后以某种可能会影响程序结果的方式使用该值时才报告对未初始化数据的访问的原因。您会得到类似“ xxx：nnn中的条件分支取决于未初始化的值”的诊断信息，有时可能很难找到它的起源。如果所有这些访问都被立即捕获，那么编译器优化的代码以及正确的手工优化的代码将产生许多误报。

说到这一点，我正在使用来自移植到Linux并在Valgrind下运行时会释放这些错误的供应商。但是供应商说服我，实际上所使用的值只有几位来自未初始化的内存，逻辑上仔细地避免了这些位。.仅使用了值的好位，而Valgrind没有能力跟踪到单个位。未初始化的材料来自读取已编码数据的位流末尾的单词，但是代码知道该流中有多少位，并且不会使用比实际更多的位。由于超出位流阵列末尾的访问不会对DSP架构造成任何损害（阵列之后没有虚拟内存，没有内存映射端口，并且地址没有包装），因此这是一种有效的优化技术。

“未定义行为”的含义并不多，因为根据ISO C，仅包括未在C标准中定义的标头，或者调用在程序本身或C标准中未定义的函数，都是未定义的示例。行为。未定义的行为并不意味着“地球上没有任何人定义”，而只是“ ISO C标准未定义”。但是当然，有时未定义的行为实际上绝对不是任何人都定义的。

#10 楼

除了您自己的程序外，我认为您不会破坏任何内容，在最坏的情况下，您将尝试从与内核未分配给您的过程的页面相对应的内存地址进行读取或写入，从而生成适当的异常并被杀死（我是说，您的过程）。