以下图表显示了相关攻击活动的工作原理：

 

请注意：其中并不包含填充字节

在上面的例子中，攻击者在发出的HeartbeatMessage当中包含了仅为1字节的有效负载，这一情况也被反映在了SSL3的length记录当中;不过payload length字段要求有效负载长度应该为65535字节。受害者忽略了SSL3记录，转而从内存接收到的HeartbeatMessage起始处开始读取65535字节的数据并将其复制到缓存当中，最终以合适的长度发送回攻击者处。由于包含大量额外字节，上图中红色单元格所示即为可能导致信息泄露的数据部分。

从代码角度分析

以下代码为OpenSSL对HeartbeatMessage输入内容的处理方式，其中p为指向该信息起始处的指针：

这样一来，信息类型就被体现在hbtype变量当中，该指针由1字节开始递增，而n2s()宏将长度为16-bit的Heartbeat有效负载写入到payload变量中并将该指针增加到2字节。接下来，pl又成为指向这部分有效负载内容的指针。

举例来说，一条Heartbeat信息中的payload length为65535字节，即：一条接收到的Heartbeat中最多可能包含64KB有效负载。代码必须将输入的HeartbeatMessage以副本形式发送回去，从而保证缓存区拥有足够的空间来保存64KB有效负载、1字节信息类型、2字节有效负载长度外加部分填充字节，具体结构如前所述。

它会利用以下代码创建HeartbeatMessage回复结构，其中bp为指向HeartbeatMessage回复起始位置的指针：

因此这部分代码会将响应类型写入到缓存起始位置、递增缓存指针、利用s2n()宏向内存中写入16-bit payload长度并以2字节为单位递增缓存指针，而后将payload的字节数量从接收到的有效负载中复制到用于回复的有效负载发送内容中。

请注意，payload由攻击者全面控制，而且64KB也足以容纳大量信息。假如由攻击者发送的HeartbeatMessage只拥有1字节有效负载，而且其payload length又与实际情况不符，那么以上代码中的memcpy()就会在接收到的HeartbeatMessage之外从起始处读取受害者的内存进程。

而这部分内存很可能包含其它意义重大的信息，例如密码内容或者来自其它客户端的加密信息等。

事实上，尽管我们了解到雅虎已经对其系统进行了修复，但该公司仍然发布了如下建议：

请不要登陆雅虎网站。目前OpenSSL漏洞Heartbleed允许攻击者提取用户名以及简单密码信息！

—Mark Loman (@markloman)，2014年4月8号

修复手段

OpenSSL 1.0.1g中的补丁从本质上讲就是一项边界检查，旨在利用SSL3结构(s3->rrec)中的正确长度记录描述输入的HeartbeatMessage。

OpenSSL是在2011年12月31号星期六午夜期间耗时61分钟完成TLS Heartbeat项目源代码提交工作的。如今我们所承受的各种威胁可谓一场姗姗来迟的安全风暴。

(责任编辑：安博涛)