心脏滴血漏洞HeartBleed CVE-2014-0160深入代码层面的分析

前几天有人问我你不是看过openssl吗？那聊聊openssl漏洞，当时我一脸迷茫。我说我知道著名的心脏滴血漏洞，但是具体漏洞是什么原因导致的没有回答上来。对于自诩看过openssl源码的人，我觉得有必要对着代码研究一下，因此就有了本文。

对于心脏滴血的详细介绍，看以参考这个网站，但是这里主要是概述性质的，并没有深入到代码层次。实际上，我简单搜索了一下，在网上有很多的分析，但是深入代码的文章，网上基本没有，也许我这篇有望成为第一篇深入代码层次解读心脏滴血漏洞的文章。由于github上没有opnessl-1.0.1f版本的代码，只有1.0.1stable。因此下载这方面代码的时候可以到这里进行下载。因为滴血漏洞的影响范围仅限于openssl1.0.1到1.0.1f之间的版本。

本文对比的是openssl1.0.1f (存在心脏滴血问题)以及1.1.0f(修复了该漏洞的)代码差异。

心脏滴血漏洞从本质上来说是在memcpy的时候，没有对拷贝的内存做合法性检查，并非网上流传的在申请内存的时候即OPENSSL_malloc没有做合法性检查。因为虽然OPENSSL_malloc没有做合法性检查，但是其并不会泄露服务器的内存数据，真正世露数据的是memcpy动作。

心脏滴血漏洞是在heartbeat (RFC6520定义的功能)中引入的，在OpenSSL中使用了编译宏OPENSSL_NO_HEARTBEATS来决定是否开启heat beat 功能。因此搜索OPENSSL_NO _HEARTBEATS可以找到相关的代码。其实在OpenSSL-1.0.1f发送方函数中，对于发送的长度是有限制的。也就是说如果使用openssl库生成的报文，长度上是没有问题的。在1.0.1f中函数ssl3_ctrl的case SSL_CTRL_DTLS_EXT_SEND_HEARTBEAT分支调用函数dtls1_heartbeat中,这其中做了如下限制OPENSSL_assert(payload + padding <= 16381)，即发送的最大报文长度是16384 (加上type一个字节，长度占两个字节)。

由于泄漏的是服务器的信息，因此定位到函数dtls1_process_heartbeat。openssl1.0.1f以及以前的版本在接收方函数，并没有做长度的限制。接收方在收到心跳报文TLS1_HB_REQUEST之后，给发送方回的响应中报文的长度，就是发送方传递过来的报文长度。如下代码:

buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);

问题主要出在memcpy，其中payload就是发送方带过来的报文长度，pl是接收方用于存储发送方发来的heartbeat请求部分的内存空间，bp是要发送的Buffer。由于前面提到发送方其实规定了能够传输的最大长度，例如发送内容的时候就做了限定，为2^14-3=16381，即接收方数组也会做限定，即pl空间有最大值。但是如果构造的heartbeat请求报文中长度超过了16381 (自行构造的异常报文)，由于pl是一个内存空间，因此在复制的时候就会发生越界。payload是一个 unsigned int 类型，因此则最大可能泄露的内存空间为2^64，即64K大小的数据。bp是要发送的Buffer，如果紧邻pl的内存数据是网站秘钥的话，则秘钥会被返回给客户端，造成了网站秘钥的泄露。如果紧邻的内存是用户名和密码，则网站的用户名和密码都会被泄露，由于64K还是一个挺大的数据空间，如果不停的对网站发起heartbeat请求，则网站秘钥，用户信息的泄露可想而知，因此这也是心脏滴血漏洞如此致命的原因。

既然知道为何泄露，那么相应的补丁也就很好打了。发送端加何限制发送的长度大小，那么接收端做同样的限制即可。例如在openssl 1.1.0f中的修复就是如下代码:

unsigned int write_length = HEARTBEAT_SIZE(payload, padding);
int r;if (write_length > SSL3_RT_MAX_PLAIN_LENGTH)return 0;

SSL3_RT_MAX_PLAIN_LENGTH的值为16384,这样发送方和接收方的长度就保持了一致。

以上就是对于心脏滴血漏洞CVE-2014-0160在代码层面的分析。当然文中是以dtls1_process_heartbeat这样的函数为例来说明，dtls是针对传输层是UDP的加密，对于传输层是TCP，相应的函数应为tls1_process_heartbeat，当然不同的openssl版本可能略有差异，但是总体上来说DTLS以及TLS都曾存在该漏洞。

本文为CSDN村中少年原创文章，转载记得加上小尾巴偶，博主链接这里。

心脏滴血漏洞HeartBleed CVE-2014-0160深入代码层面的分析相关推荐

心脏滴血漏洞详解及利用--HeartBleed With OpenSSL
[事件规则] OpenSSL"心脏出血"漏洞是一个非常严重的问题.这个漏洞使攻击者能够从内存中读取多达64 KB的数据.也就是说,只要有这个漏洞的存在,在无需任何特权信息或身份验证 ...
“心脏滴血漏洞”测评经验分享
"心脏滴血漏洞"测评经验分享 1 前言 1.1 编写目的经验分析贴,赚C币买文章: 1.2 读者对象本文档读者对象为:测评相关工程师.项目管理者.测试工程师.质量管理人员.文档 ...
【web攻防】破壳漏洞【CVE-2014-6271】与心脏滴血漏洞【CVE-2014-0160】 docker 复现学习过程
其实最近的确是想更新一些文章的,但一直在忙于挖洞和挖洞技巧学习,前者肯定不能发真实案例,后者学的太零碎太杂,自己也处于一个积累的过程,发一些边边角角的内容也没意思. 虽然相比以前的确有了一点进步,但我 ...
“心脏滴血”漏洞复现
"心脏滴血"简介: Heartbleed漏洞是由于未能在memcpy()调用受害用户输入内容作为长度参数之前正确进行边界检查.攻击者可以追踪OpenSSL所分配的64KB缓存.将超 ...
心脏滴血漏洞利用（CVE-2014-0160）
0x00 前置知识心脏滴血漏洞复现(CVE-2014-0160) - 知乎 1.心脏滴血简介心脏出血漏洞"是指openssl这个开源软件中的一个漏洞,因为该软件使用到一个叫做heartb ...
心脏滴血漏洞复现(CVE-2014-0160)
漏洞范围: OpenSSL1.0.1版本漏洞成因: Heartbleed漏洞是由于未能在memcpy()调用受害用户输入内容作为长度参数之前正确进行边界检查.攻击者可以追踪OpenSSL所分配的64 ...
一次心脏滴血漏洞的bug处理过程
一个p2p平台,一次内部安全事件的处理过程,一个关乎投资人利益的网络投资平台,一个无知者无畏的年代.口口声声对外宣称安全.可靠.高收益.-- [步骤] 1.对应用https的系统进行ssl协议已公开漏 ...
心脏滴血漏洞(CVE-2014-0160)分析与防护
一.漏洞简介 2014年4月7日,OpenSSL发布安全公告,在OpenSSL1.0.1版本至OpenSSL1.0.1f Beta1版本中存在漏洞,该漏洞中文名称为心脏滴血,英文名称为HeartBle ...
OpenSSL心脏滴血漏洞（CVE-2014-0160）
一.漏洞介绍 2014年,互联网安全协议OpenSSL被爆出存在一种十分严重的漏洞. 在黑客社区,被命名为"心脏滴血" ,黑客通过利用该漏洞,可以获取到%30开头的https网站的 ...

心脏滴血漏洞HeartBleed CVE-2014-0160深入代码层面的分析

心脏滴血漏洞HeartBleed CVE-2014-0160深入代码层面的分析相关推荐

最新文章

热门文章