heartbleed bug是C中典型缓冲区溢出漏洞的表现吗？

在我们第一次关于安全性的CS讲座中，我们了解了C的问题，没有检查所谓的缓冲区长度，以及利用此漏洞的不同方式的一些示例

在本例中，它看起来像是一个恶意读取操作，应用程序只是读取了多少字节的内存

我断言Heartbleed bug是C缓冲区长度检查问题的表现，对吗

为什么恶意使用在试图读取另一个应用程序的内存时没有导致分段错误

在写入内存（然后从内存中读取）之前简单地将内存归零会导致分段错误吗？或者这在不同的操作系统中有所不同？还是在其他环境因素之间

显然，无法确定漏洞的利用情况。这是因为heartbeat函数在调用时不记录日志吗？否则，对~64k字符串的任何请求都可能是恶意的吗

我断言Heartbleed bug是C缓冲区长度检查问题的表现，对吗

对

heartbleed bug是C中典型缓冲区溢出漏洞的表现吗

不可以。“经典”缓冲区溢出是指在堆栈分配的缓冲区中写入的数据超过其所能容纳的数据量，而写入的数据是由恶意代理提供的。恶意数据溢出缓冲区并覆盖当前方法的返回地址。当该方法结束时，它将返回一个包含攻击者选择的代码的地址并开始执行它

相比之下，heartbleed缺陷不会覆盖缓冲区，也不会执行任意代码，它只是读取内存中很可能有敏感数据的代码中的越界数据

为什么恶意使用在试图读取另一个应用程序的内存时没有导致分段错误

它没有尝试读取另一个应用程序的内存。该漏洞读取当前进程的内存，而不是另一个进程的内存

为什么恶意使用在试图读取缓冲区边界之外的内存时没有导致分段错误

这是这个问题的重复：

分段错误表示您触摸了操作系统内存管理器尚未分配给您的页面。这里的错误是您接触了堆管理器未分配给您的有效页面上的数据。只要页面有效，就不会出现错误。通常，堆管理器会向操作系统请求一大块内存，然后将其分配给不同的分配。就操作系统而言，所有这些分配都位于有效的内存页上

取消引用null是一个错误，因为操作系统从不将包含零指针的页面设置为有效页面

更一般地说：不需要编译器和运行时来确保未定义的行为会导致segfault；UB可以导致任何行为，包括无所事事。有关此问题的更多想法，请参见：

我抱怨UB在安全关键代码中应始终等同于segfault，并指出了一些关于漏洞静态分析的讨论，请参阅今天的博客文章：

在写入内存（然后从内存中读取）之前简单地将内存归零会导致分段错误吗

不太可能。如果读取超出范围不会导致segfault，则写入超出范围不太可能导致segfault。内存页可能是只读的，但在这种情况下似乎不太可能

当然，将所有不应该出现的内存归零的后续后果是整个节目中的seg故障。如果在归零的内存中有一个指针，您稍后会取消引用，这就是取消引用null，这将产生一个segfault

这在不同的操作系统中有所不同吗

这个问题很模糊。让我重新措辞

不同的操作系统和不同的C/C++运行库是否提供了不同的策略来分配虚拟内存、分配堆内存以及识别内存访问何时超出界限

对,；不同的事情是不同的

还是在其他环境因素之间

比如

显然，无法确定漏洞的利用情况。这是因为heartbeat函数在调用时不记录日志吗

对

当然，对~64k字符串的任何请求都可能是恶意的

---

我没有遵循你的思路。导致请求可能是恶意的原因是发送的字节和请求回显的字节之间不匹配，而不是请求回显的数据的大小。

不会发生分段错误，因为访问的数据与请求的数据相邻，并且通常在同一进程的内存中。如果请求足够大，我想可能会导致异常，但这样做不符合开发人员的利益，因为进程崩溃会阻止他们获取数据

为了清楚地解释，这部漫画很难再好了：

---

1。对2.这是同一个节目。3.不是。由服务器进程所有，这就是导致“出血”的原因。4.没有keep alive的日志，这就是我向您发送1000字节（现在回显）的地方，但我只向您发送1字节。。。嘿，看，你发回了999个“其他”字节。我要说的是，读取你不拥有的内存并不一定会导致SEGFULT，这只是一个未定义的行为。为什么这个问题表明缓冲区溢出是CIn独有的？关于最后一个问题，我会说任何大回送请求都是恶意的。它正在消耗服务器资源（带宽，这需要花钱）