心脏流血漏洞相关内容有哪些

2014年4月，心脏相关OpenSSL的流血漏洞代码仓库里躺着一行没人注意的`memcpy`。就是内容这行代码，让全球大约17%的心脏相关HTTPS服务器在接下来几天里变成了漏水的桶——攻击者能一勺一勺舀走服务器内存里的私钥、会话Cookie、流血漏洞用户密码。内容这个漏洞后来被命名为“心脏流血”（Heartbleed），心脏相关编号CVE-2014-0160。流血漏洞

问题出在TLS心跳扩展上。内容这个扩展本来是心脏相关为了让客户端和服务器保持连接活跃，客户端发一个“心跳”包，流血漏洞里面带一段数据和一个长度字段，内容服务器收到后把数据原样返回。心脏相关OpenSSL的流血漏洞实现里，服务器读取长度字段后，内容没有检查实际数据是否真的有那么长，直接按长度字段的值从内存里复制数据返回。攻击者把长度字段改成65535，但实际只发1字节数据，服务器就会从内存里多读65534字节返回。这些多出来的内存里有什么？可能是私钥，可能是其他用户刚提交的密码，可能是任何东西。

这个漏洞的可怕之处在于，它不需要攻击者登录，不需要复杂利用链，一个简单的Python脚本就能反复触发，每次捞一点内存，拼凑起来就能拿到关键数据。当时有安全研究员做了测试，用几行代码就从一台服务器上抓到了私钥。私钥泄露意味着什么？攻击者可以解密之前截获的加密流量，可以冒充服务器，可以做中间人攻击。而且因为漏洞在OpenSSL里，Apache、Nginx、邮件服务器、VPN网关，只要用了这个库，全都中招。

修复其实很简单。OpenSSL在1.0.1g版本里加了一行长度校验：如果声明的心跳数据长度超过实际发送的数据长度，直接丢弃这个包。就这么一行`if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0;`，堵住了漏洞。但问题在于，大量服务器不会立刻升级。漏洞公开后，互联网上出现了扫描器，批量检测哪些服务器还在“流血”。那几天，运维人员的电话被打爆，安全团队通宵打补丁。有些公司甚至直接吊销了SSL证书，重新签发，因为无法确认私钥是否已经泄露。

心脏流血事件暴露的不只是OpenSSL的代码质量问题，还有整个开源基础设施的维护困境。OpenSSL当时只有几个全职开发者，大部分是志愿者，却支撑着全球互联网的加密通信。漏洞公开后，Linux基金会搞了核心基础设施计划，给OpenSSL等项目拨款，但那是后话了。更直接的影响是，这件事让“内存安全”成了热门话题。用C语言写加密库，手动管理内存，一个边界检查疏忽就是灾难。后来Rust语言在系统编程领域崛起，跟这类漏洞反复出现有很大关系。

现在回头看，心脏流血已经成了一个经典案例。CTF比赛里经常有模拟题，安全课程必讲，面试也常问。它的教训很直白：输入验证不能省，边界检查不能省，开源项目不能只靠情怀维护。那行缺失的校验代码，代价是无数台服务器被扒光，无数用户数据裸奔。技术债这东西，平时看不见，一旦爆了，就是全球性的。