cve20042761漏洞修复

2014年9月24日，洞修Bash官方发布了一个补丁，洞修编号CVE-2014-6271。洞修这个漏洞的洞修CVSS评分是10.0——满分。听起来像天塌了，洞修但说实话，洞修当时很多人第一反应是洞修：Bash？那个天天在用的shell？能出什么事？

出事的方式很刁钻。Bash支持一种叫“环境变量函数”的洞修机制，简单说就是洞修你可以把一段函数定义塞进环境变量里，Bash启动时会把它还原成函数。洞修问题出在解析上：Bash没有在函数体结束后停下来，洞修后面跟的洞修任何命令都会被一并执行。这意味着，洞修只要一个程序把用户可控的洞修数据传进了环境变量，再调用Bash，洞修攻击者就能在目标机器上跑任意代码。

CGI是最典型的入口。当时大量Web服务器用Bash写CGI脚本，HTTP请求头里的User-Agent、Referer这些字段会被塞进环境变量。攻击者构造一个这样的请求头：

User-Agent: () {  :; }; /bin/bash -c 'cat /etc/passwd'

服务器上的Bash一解析，/etc/passwd的内容就回来了。不需要认证，不需要交互，一个curl命令搞定。DHCP客户端、SSH的ForceCommand、甚至某些Linux桌面环境的服务，都是潜在的触发路径。影响范围覆盖了从嵌入式设备到大型数据中心的几乎所有Linux和macOS系统。

修复过程比想象中混乱。Bash维护者Chet Ramey在漏洞公开当天就发了补丁，但补丁本身不完整。研究人员很快发现绕过方法，于是有了CVE-2014-7169。接着是第三轮、第四轮修补。一周之内Bash连发了四个版本，每个都号称修好了，每个都被找到新的绕过。那段时间运维圈的状态基本是：刚推完补丁，看到新CVE，骂一句，继续推。

我印象最深的是一个朋友的经历。他所在的公司有几千台服务器，补丁管理流程走完至少要三天。第一天修了CGI入口，第二天发现DHCP客户端也有问题，第三天SSH的ForceCommand又爆了。他跟我说：“感觉像在堵漏水的管子，堵一个冒一个。”

最终稳定版本是Bash 4.3 patch 25。修复思路其实不复杂：在函数定义解析时严格限制，遇到}就停止，不再执行后续内容。但代码改动的连锁反应导致前几个补丁引入了新的解析问题，这也是为什么修了这么多次。

这件事给我留下两个很具体的教训。一是“古老代码的默认信任”极其危险。Bash的环境变量函数机制是上世纪八十年代末引入的，那个年代没人考虑安全边界，能用就行。二十多年后，这个设计决策变成了满分漏洞。二是补丁质量本身需要验证。CVE-2014-6271的第一次修复如果足够严谨，后面三个CVE根本不会存在。

如果你现在还在维护老系统，检查一下Bash版本。bash --version，低于4.3 patch 25的，别犹豫，升级。别觉得内网就安全——这个漏洞的利用成本低到离谱，一条构造好的HTTP请求就够了。