2014年9月24日，漏洞Red Hat安全团队公开了一个编号为CVE-2014-6271的出现漏洞。这个漏洞影响的系统不是某个冷门软件，而是漏洞几乎所有主流Linux发行版和macOS系统都默认安装的GNU Bash。换句话说，出现你手边的系统Ubuntu服务器、CentOS虚拟机、漏洞甚至那台MacBook，出现当时都可能已经踩在坑里了。系统

Bash是漏洞什么？它是Bourne-Again Shell的缩写，Unix和Linux世界里最常用的出现命令行解释器。你打开终端敲的系统每一条命令，背后都是漏洞它在解析执行。问题出在Bash处理环境变量时的出现一个缺陷：它会把函数定义后面夹带的额外代码也一并执行。攻击者只要构造一段特殊的系统环境变量，就能让Bash在启动时执行任意命令。不需要密码，不需要登录，只要目标系统上有一个能触发Bash调用的入口——比如Apache的CGI脚本、SSH的ForceCommand、甚至DHCP客户端——就能远程拿到shell权限。

这个漏洞的严重程度，从它的绰号就能看出来：Shellshock， shell休克。CVSS评分直接拉满到10.0。当时全球至少有5亿台服务器和设备暴露在风险中，从Web托管平台到嵌入式路由器，从Docker容器到苹果的OS X。苹果在漏洞公开后不到一周就发布了OS X Bash更新，但很多老版本Mac用户根本不知道自己的系统里藏着这么个东西。

为什么影响面这么大？因为Bash太老了。它1989年由Brian Fox编写，作为Bourne Shell的替代品。那个年代的设计者压根没考虑过“环境变量里可能藏恶意代码”这种事。函数导出功能是后来加的，加的时候也没做严格的输入过滤。三十多年过去，Bash成了Linux世界的默认shell，几乎无处不在，这个设计缺陷也就跟着潜伏了三十多年。

修复过程也一波三折。第一版补丁出来没几天，就被发现可以绕过。安全研究员Tavis Ormandy在推特上直接说“补丁不完整”。Red Hat不得不连续发布多个更新版本。那段时间运维圈子里人人自危，因为Bash的调用路径太深了，你根本不确定系统里哪个服务会在什么条件下触发它。有人开玩笑说，这就像你发现家里所有水管都连着同一个漏水的阀门，但你不知道哪个水龙头会先爆。

我印象最深的是当时一个朋友的经历。他管着几十台CentOS 6的Web服务器，跑的是老式CGI程序。漏洞公开那天晚上他连夜打补丁，结果第二天发现有一台机器上的监控脚本自己挂了——因为那个脚本依赖Bash的一个特性，而新补丁把那个特性一起干掉了。他只好临时把脚本改成sh执行。这种连锁反应在Shellshock的修复过程中非常普遍，补丁本身没问题，但Bash被太多东西依赖了，动一发牵全身。

从技术角度看，Shellshock暴露了一个更根本的问题：我们太信任那些“基础设施级”的软件了。Bash、OpenSSL、glibc，这些东西默默运行在底层，没人会天天盯着它们看。直到Heartbleed和Shellshock接连爆发，大家才意识到，这些老家伙的代码质量可能还不如你上周写的那段Python脚本。GNU项目后来给Bash加了更严格的解析逻辑，但那种“默认信任输入”的Unix哲学，在安全对抗里始终是个软肋。

现在回头看，Shellshock的教训不是“赶紧打补丁”这么简单。它提醒我们，那些看起来稳定、成熟、用了十几年的基础组件，可能只是没人去仔细审查它的边界条件。Linux系统本身没问题，macOS也没问题，问题在于Bash这个组件在它们里面待得太久、扎根太深，以至于所有人都忘了它也会出错。漏洞出现于什么系统？答案是：任何装了Bash的系统。而那个名单，在2014年几乎就是“所有系统”。