大家好，又见面了，我是你们的朋友全栈君。
此次名为Heartbleed的OpenSSL漏洞引发了极其恶劣的影响，而为此暂时切断互联网连接肯定也不算什么理想的解决方案。仅仅由于广泛使用的加密机制中存在一丁点微小缺陷，如今任何家伙都能轻松潜入存在漏洞的系统——包括银行HTTPS服务器以及个人VPN——并疯狂窃取密码、登陆cookie、个人加密密钥等等。
现在已经是2014年了，安全保障工作为何仍然如此不堪?
只需一份利用Metasploit引擎的简单脚本外加短短几秒钟，恶意人士即可从依赖于OpenSSL 1.0.1到1.0.1f版本进行TLS加密的系统内存中提取到敏感数据。根据我们掌握的情况，这一漏洞影响到的网站约为五十万个、占总体受信网站中的17.5%，此外任何使用上述OpenSSL版本的客户端软件、邮件服务器、聊天服务等也都在受影响范围之内。
本周一开始已经有不少热门网络服务陆续针对这一漏洞发布修复补丁;大家可以利用相关工具检查自己的系统是否已经中招(当然，风险要由各位自己承担)，同时也别忘了为自己已经受到感染的系统安装OpenSSL修复补丁。除此之外，我们还需要更改密码、转储会话cookie并对数据风险加以评估。
如果大家还不了解Heartbleed是怎么回事，这里提供概括描述：
这项严重缺陷(CVE-2014-0160)的产生是由于未能在memcpy()调用受害用户输入内容作为长度参数之前正确进行边界检查。攻击者可以追踪OpenSSL所分配的64KB缓存、将超出必要范围的字节信息复制到缓存当中再返回缓存内容，这样一来受害者的内存内容就会以每次64KB的速度进行泄露。大家可以点击此处获取修复补丁，需要强调的是此次问题远比苹果前一阵子曝出的安全问题严重得多。
问题源自TLS Heartbeat扩展
这一漏洞藏身于OpenSSL的TLS Heartbeat扩展当中：这是一项持续作用型功能，其中一个连接端会向另一端发送任意数据的有效负载，对方则发回对应数据的精确副本以确保传输过程一切正常。根据官方提供的标准说明，Heartbeat信息在C语言中表现为以下形式：
这条HeartbeatMessage通过SSL3_RECORD结构——一种SSL/TLS通信基础构建块——进行传输。SSL3_RECORD中的关键性字段如下所示，其中length代表接收到的HeartbeatMessage内容为多少字节、data则为指向该HeartbeatMessage的指针。
更明确地进行解释，SSL3记录中的data指向接收到的HeartbeatMessage的起始位置，而length代表接收到的HeartbeatMessage的字节数量。与此同时，HeartbeatMessage中的payload length代表被发回的随意有效负载的字节数量。
发出HeartbeatMessage的一方对payload length拥有控制权，不过正如我们所看到，SSL3_RECORD中的length字段并没有经过验证、而这一状况就成了攻击者实现内存溢出绝佳机会。
以下图表显示了相关攻击活动的工作原理：
请注意：其中并不包含填充字节
在上面的例子中，攻击者在发出的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项目源代码提交工作的。如今我们所承受的各种威胁可谓一场姗姗来迟的安全风暴。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/159945.html原文链接：https://javaforall.net
