OpenSSL bug 和 linux 进程内存管理答案

【问题标题】：OpenSSL bug and linux process memory managementOpenSSL bug 和 linux 进程内存管理
【发布时间】：2014-05-23 06:38:56
【问题描述】：

对于最近的 OpenSSL 错误，用户空间应用程序是否可以通过 mmap 读取其他进程的内存？这是参考http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html中的错误描述

我想，上面文章中关于通过 memcpy 读取内存的担忧（因为它根据数据包长度中提供的内容复制内存）是有效的，因为如果你碰巧在那个位置有信用卡信息，它可以发回给生成数据包的用户。

【问题讨论】：

这不太可能。 ssl 代码中的 ->payload 字段是动态分配的，将由 linux 通过 /dev/zeroo 的异常 mmap 获得。（以几 MB 为单位，IIRC）不同映射在同一个 64 K 窗口中的机会非常小。此外，内存映射会以“堆”可以线性扩展的方式排列，因此文件映射将被放置在不同的区域。

【解决方案1】：

这完全取决于您的意思，但简短的回答是“是”。

一个简单的例子是两个应用程序都加载了相同的共享库。从两个进程中读取共享代码都是可见的。

您还可以选择使用 mmap 映射内存，以便它们可以在进程之间共享，方法是使用 MAP_SHARED 标志。这是进程间通信的一种方法。

至于能够读取未使用共享标志映射的内存，这对于用户空间应用程序来说是不可能的。

鉴于该错误，您可以尝试打开到 localhost 的 https 连接。谁知道你会发现什么。

【讨论】：

我相信攻击者需要控制一个指针来读取，我认为这还没有发生（在这里纠正我）。另外，堆内存和共享内存的内存通常差别很大。所以它不足以读取堆的末尾（这可能会导致SIGSEG）。也许 POC 需要尝试将小型 SSL 记录与大型 Heartbeat 消息相结合，以覆盖某个位置。
覆盖会导致segment fault，不知道是不是通过mmap读取不属于进程的随机内存也会导致seg fault？
据我所知，共享库只共享代码空间，但共享库的任何内存分配都是在应用程序的堆或堆栈中完成的。
什么也没写。该请求只允许寻址超出预期读取的内存，最大为 64K。并且该内存可能恰好包含（私有）密钥数据。