OpenSSL心血漏洞分析「建议收藏」

大家好，又见面了，我是你们的朋友全栈君。

SSL 是一种理论，而其具体实现，就有好多了，firefox有自己的实现，旧版本的chrome有自己的实现，Openssl也属于实现的一种。

该漏洞并不是协议上的漏洞，而是针对某个实现的漏洞，说简单点就是：代码写的烂或者考虑不全面。

受影响的OpenSSL版本：

OpenSSL 1.0.2-beta

OpenSSL 1.0.1 – OpenSSL 1.0.1f

1：为什么叫 心血漏洞

SSL有一个特性，相当于TCP的keepalive 特性，即一端发送特定的报文到对端，如果对端收到，并且回复，就表示对方未断开连接，并且自己也不会断开连接。

该功能的英文名叫做：Heartbeat ，发现漏洞的人称这个漏洞为Heartbleed，翻译成中文就叫心血漏洞。

该功能在RFC 6520中详细描述，主要讲解了一些报文格式。

2：心血漏洞原理

简要概述就是说，OpenSSL在解析 对端发送的Heartbeat 请求报文的时候没有判断边界值。

我们先来看看Heartbeat 请求报文格式：

第一部分 类型 Content type

第二部分 协议版本 Version

第三部分 长度 Length

Length指定了后面数据的长度。

而Length 指定的数据（即上图中的Encrypted Heartbeat Mesaage） 包括2部分： 1：序号 2：填充 协议要求，Heartbeat 响应的序号，必须和Heartbeat 请求的序号相同，padding是随机值。

但是我们看看openssl是怎么解这个报文的：

开始时，p 指向的是read_buf，OpenSSL的流程就是解析这个报文。

提取 报文 中 Length 字段， 赋值到payload中，并未判断报文 后面的长度是否是 Length 指定的长度。因为客户端可能指定了payload 长度是0x4000，而后面的实际数据起始就1个字节。到目前为止，还未出现致命的信息泄露问题。

紧接着，准备构造Heartbeat 响应：

上面说过，根据协议要求，Heartbeat 响应的序号，必须和Heartbeat 请求的序号相同。 OpenSSL为了图方便，直接把 Heartbeat 请求报文拷贝过来了（因为请求报文中存在自己需要的序号）！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

P1 指向了read_buf的payload，OpenSSL直接从read_buf中的payload起始处拷贝了payload 长度的数据到字节的write_buf。

read_buf一共也就16k长度，如果客户端故意写的payload 是64k，那么很显然，OpenSSL进程空间的(64k-16k)的内存（可能是会话结构体中的其他字段，包括存放私钥等其他私密信息的内存）透露给客户端了。

3：OpenSSL对该问题的修复如下

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/160511.html原文链接：https://javaforall.cn