心血漏洞修复工具

2014年4月7日，心血修复一个叫Sean Cassidy的漏洞安全研究员在GitHub上提交了一份概念验证代码。他写这段代码只花了不到两小时，工具但它能让全球超过50万台服务器在握手阶段直接吐出64KB的心血修复内存内容——用户名、密码、漏洞私钥、工具Session Token，心血修复全在里面。漏洞这个漏洞后来被命名为Heartbleed，工具中文叫"心血漏洞"。心血修复

OpenSSL是漏洞当时互联网的底层地基。你访问HTTPS网站，工具背后大概率就是心血修复它在干活。而Heartbleed的漏洞成因，说白了就一行代码少了个边界检查：客户端说我发过来3个字节，工具服务器你回给我65535个字节吧。服务器居然照做了。它不检查实际收到的数据长度，直接把内存里后面跟着的内容一起打包发回去。攻击者要做的只是反复发这种"我只有3个字节但你给我6万字节"的请求，像用吸管一点点吸走服务器的记忆。

修复本身其实不复杂。OpenSSL在1.0.1g版本里加了一个长度校验：收到的payload长度和声明的是否一致，不一致就丢弃。补丁代码量很小，几行而已。麻烦的是善后。

你得先搞清楚自己哪些服务用了受影响版本。Linux发行版各有各的包管理方式，CentOS上rpm -q openssl，Ubuntu上dpkg -l | grep openssl，但查出来版本号还不够——有些发行版会backport补丁，版本号看着老，实际上是安全的。你得看具体的编译时间戳或者changelog。很多运维在那几天被这个坑得够呛。

确认受影响之后，升级只是第一步。真正要命的是：你的私钥可能已经泄露了。这意味着你得重新生成密钥对、重新申请证书、重新部署。对于一个大公司来说，这涉及几百上千个域名和服务的证书轮换，流程走下来少说几天，多则几周。Cloudflare当时发了一篇博客说他们在几个小时内完成了证书轮换，但那是极少数反应极快的团队。更多中小站点拖了一两周才搞定。

还有Session的问题。用户登录态可能被窃取，理论上你得强制所有人重新登录，清空所有Session。这对用户体验的伤害是直接的，但不做就是留着一个随时可能被利用的口子。

我当时帮几个朋友的站点做排查，发现一个挺普遍的现象：很多人升级了OpenSSL，但忘了重启依赖它的服务。Nginx、Apache、MySQL这些进程在启动时加载了OpenSSL的动态链接库，你不重启它们，跑在内存里的还是旧版本。用lsof | grep libssl能查出来哪些进程还在用旧库。这个细节很容易被忽略。

检测工具方面，当时流行几个：一个是SSLMate做的在线检测页面，输入域名就能告诉你是否受影响；另一个是Nmap的ssl-heartbleed脚本，适合批量扫描内网。我个人更推荐后者，因为在线工具你没法确认它到底测了什么，而Nmap脚本的逻辑是透明的，你可以自己审计。

这件事之后，OpenSSL项目拿到了不少捐款，也终于开始做代码审计了。但说实话，一个支撑了半个互联网的加密库，长期只有两三个全职维护者，这本身就比Heartbleed更让人后背发凉。漏洞修了，但那套"关键基础设施靠志愿者维护"的模式没变。下一次Heartbleed只是时间问题。

很赞哦!（62）