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

OpenSSL心血漏洞分析「建议收藏」SSL是一种理论,而其具体实现,就有好多了,firefox有自己的实现,旧版本的chrome有自己的实现,Openssl也属于实现的一种。   该漏洞并不是协议上的漏洞,而是针对某个实现的漏洞,说简单点就是:代码写的烂或者考虑不全面。 受影响的OpenSSL版本:OpenSSL1.0.2-betaOpenSSL1.0.1-OpenSSL1.0.1f 

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

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

 

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

 

受影响的OpenSSL版本:

OpenSSL 1.0.2-beta

OpenSSL 1.0.1 – OpenSSL 1.0.1f

 

1:为什么叫 心血漏洞

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

 

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

 

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


2:心血漏洞原理

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

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

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


第一部分 类型 Content type

第二部分 协议版本 Version 

第三部分 长度 Length

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


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

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

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


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

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

紧接着,准备构造Heartbeat 响应:

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


    上面说过,根据协议要求,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对该问题的修复如下

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

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/160511.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)
blank

相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号