Shellshock并没有被夸大，在很长一段时间内，各种规模的系统都将受到影响。现在赶紧打补丁！

　　在笔者看来，Shellshock Bash漏洞带来的影响可能会超过Heartbleed。笔者在不同地理位置和不同供应商的几台服务器已经检测到漏洞利用。问题何在？这个漏洞太容易被攻击者利用。

　　事实上，这是Bash中22年之久的漏洞，该漏洞导致shell在调用匿名函数后执行交付的代码。让事情更糟糕的是，这可以发生在shell在评估环境变量的时候。

　　一个很简单的例子：如果你可以构建一个HTTP表头，例如包含一个类似用户代理字符串(包含正确语法)的变量，然后把该请求传输到web服务器，该服务器会调用Bash作为CGI脚本，或者以PHP、Java、Python或其他语言发布system()或popen()调用，并传递这些变量到Bash，你就可以破坏系统。非常重要的是要注意，这只会影响作为CGI运行的代码；这并不会影响运行mod_php的PHP代码。我们建议你以可以通过系统调用Bash的所有语言来全面测试代码。

　　同样地，为了利用这个漏洞，我们需要执行以下操作：

　　1. 运行代码的Web服务器最终调用Bash和传递环境变量

　　2. 有人发现和请求页面或脚本同时注入恶意表头

　　这看起来并不是很难。

　　攻击者可以如何利用这个漏洞？在用户运行Web服务器进程时攻击者可以发出命令。这并不意味着他们有root权限，但他们可以发出一组命令(在这里就不详述了)可以通过使用Web服务器已经存在的常用*nix工具来创建交互式shell。他们还可以导致文件上传到其他服务器，或者他们可以使用服务器的shell权限作为未授权用户做各种事情。这并不是立即生根，但是让人非常不舒服的情况。

　　如果有服务器运行Bash脚本作为CGI，这只能被认为是可怕的安全做法，而且非常容易受到攻击。不会进行System()或popen()调用的代码，以及仅在身份验证操作过程中进行调用的代码不太可能受到攻击，不会向匿名访问公开这些调用脚本的代码同样也不会。此外，如前所述，这些调用必须传递环境变量才能让漏洞显现。

　　这仍然留下了巨大的攻击空间，并且我们已经看到了现实中的证据。事实上，单行curl命令可以用来利用这个漏洞，而且不需要嗅探或编码。此外，这个漏洞可以被用来通过传递恶意字符(由客户端方面运行的Bash添加到环境辩论中)来利用*nix DHCP客户端，并且SUID漏洞可能通过这种方法获取更多的root访问权限。然而，这些一般都是本地漏洞利用，并不是远程。

　　在笔者服务器出现的漏洞利用正在使用用户代理字符串，当然这些漏洞利用尝试被记录在日志中。这些看起来像是CPanel漏洞利用，如果是这样，大量VPS和托管服务器都将在短期内受到影响。很多这些系统运行CPanel来提供GUI前端到Linux服务器管理。笔者猜想，大多数这些漏洞利用将会瞄准将是网络，在笔者访问日志中的漏洞利用似乎只是试图ping到特定IP地址，可能是为了搜集易受攻击系统的清单，而攻击者则正在忙于编码实际漏洞利用。时间将会为我们揭晓答案。

　　然后是所有固定/嵌入式系统，例如防火墙设备和路由器，以及可能或可能不运行Bash的其他系统，以及可能或可能不通过其Web UI进行Bash调用的系统。笔者认为，很多系统调用回shell来运行各种小型诊断命令，希望这些有某种形式的身份验证，或者它们正在运行ash，而不是sh或Bash。

　　我们可能会发现一大堆以这样或那样的方式调用Bash的系统，这些系统都需要修复或脱机。一旦发现这样的系统，它们受到攻击只是时间问题。

　　现在，我们能做的就是打补丁。Red Hat、Ubuntu和其他Linux版本以及各种BSD已经开始推出补丁，至少部分帮助消除该漏洞，虽然Bash维护者发布的最初补丁可能不够用。在接下来的几天里，我们将会看到新一轮的补丁。