在http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html上有一个写得很好的分析，其中包含代码示例。

作者Sean Cassidy指出（强调我的）：

如果请求者实际上并没有像她说的那样提供有效载荷字节怎么办？如果 pl 真的只有一个字节怎么办？然后从 memcpy 读取将读取 SSLv3 记录附近的任何内存。

显然，附近有很多东西。

老实说，我对发现 Heartbleed 漏洞的人的说法感到有些惊讶。当我听说它时，我认为 64KB 不足以查找密钥之类的东西。至少在 x86 上，堆会增长，所以我认为 pl 会简单地读入新分配的内存，例如 bp。密钥等会更早分配，因此您将无法读取它们。当然，对于现代 malloc 实现，这并不总是正确的。

此外，您将无法读取任何其他进程的内存，因此这些“业务关键文档”需要位于进程的内存中，小于 64KB，并且位于 pl 附近。

一种替代的观点从埃里克Cabetas的包括安全，评论Reddit上：

正在和我的朋友讨论这个错误。他认为可以通过在堆中使用各种特定大小的分配来读取堆碎片周围的 64k 块，而不是以 OP 链接中的 Sean 所暗示的线性方式来利用它。在思考了ptmalloc/linux的分配方式之后，我认为这是肯定的。来自 codenomicron 的 .fi 家伙是敏锐的家伙，我敢打赌他们能够在实验室环境中正确分配。

编辑：肖恩已更新：

显然，附近有很多东西。

使用 malloc 动态分配内存有两种方式（至少在 Linux 上）：使用 sbrk 和使用 mmap。如果内存是用 sbrk 分配的，那么它使用旧的堆增长规则并限制可以找到的内容，尽管多个请求（尤其是同时）仍然可以找到一些有趣的东西。

但是，如果使用 mmap，则所有赌注都将关闭。任何未使用的内存都可以分配给 mmap。这是针对 Heartbleed 的大多数攻击的目标。

最好的部分是：您请求的块越大，mmap 而不是 sbrk 服务的可能性就越大。

添加@scuzzy-delta 的答案：根据定义，应用程序代码中的缓冲区溢出仅影响应用程序代码。操作系统保持各个进程之间的隔离，不允许一个进程访问另一个进程的内存空间。

如果缓冲区溢出是“写”说服（攻击者强迫目标写入超出缓冲区末尾的字节），那么这可能会变成恶意劫持，其中攻击者控制目标应用程序，并使它做它的投标。应用程序级别的权限已经足以造成相当大的恶作剧，包括读取（例如）所有浏览器的配置文件、抓取屏幕内容和键盘条目等等（当它发生在“客户端”端时，例如在浏览器中） ）。但是，在这种情况下，“heartbleed”漏洞是“读取”溢出，会泄露数据但不会影响目标系统。这排除了敌对劫持的直接风险及其可怕的后果。

然而...

从目标进程的应用内存中获取秘密可能会被用于更广泛的攻击。例如，如果目标是 Web 服务器，heartbleed 问题可能会显示（如果运气好的话）一些其他用户的名称和密码，然后可以使用这些用户作为这些用户登录。这可能是有问题的。

对于Web浏览器，即客户端，可能会注意到一些浏览器习惯于启动不同的进程实例，以避免长时间运行会话中的内存碎片问题，也避免在Flash插件时丢失整个浏览器崩溃。然而，并非所有浏览器都这样做——即使对于那些这样做的人，他们也没有系统地这样做。他们遵循启发式方法，以便在单个进程中将选项卡“组合在一起”。

额外的一点是，这些进程经常使用一些共享内存来交换一些需要的信息，特别是密码和 cookie 缓存以及 SSL 会话。正是攻击者想要获得的那种多汁的数据。

从好的方面来说，攻击客户端需要客户端与之通信的服务器运行攻击。它不能由攻击者发起；它必须等待客户端连接。