我的 bash 容易受到攻击吗？

这个简单的命令足以测试您的 bash 版本是否易受攻击：

x='() { :;}; echo VULNERABLE' bash -c :

没有必要打印额外的文本来表示该命令已实际运行，因为当其启动环境中的变量包含修补漏洞的利用代码时，修补版本的 bash 将报告警告。

在易受攻击的系统上：

$ x='() { :;}; echo VULNERABLE' bash -c :
VULNERABLE

在打补丁的系统上：

$ x='() { :;}; echo VULNERABLE' bash -c :
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'

有关此功能和不测试的内容以及原因的详细说明，请参阅下面的“其他函数解析错误”。

我的系统易受攻击吗？

如果您的 bash 不易受攻击，那么您的系统也不会易受攻击。

如果您的 bash 易受攻击，那么您的系统也易受攻击，因为它使用 bash 以及 CGI 脚本、DHCP 客户端和受限 SSH 帐户等攻击媒介。检查是否/bin/sh是 bash 或其他一些 shell。该漏洞存在于特定于 bash 的功能中，其他 shell（如 dash 和 ksh）不受影响。您可以通过运行与上述相同的测试来测试默认 shell，sh而不是bash：

x='() { :;}; echo VULNERABLE' sh -c :

• 如果您看到一条错误消息，那么您的系统有一个修补过的 bash 并且不容易受到攻击。
• 如果您看到VULNERABLE，那么您系统的默认 shell 是 bash 并且所有攻击向量都是一个问题。
• 如果您没有看到任何输出，那么您系统的默认 shell 不是 bash，并且只有使用 bash 的系统部分容易受到攻击。检查：
  • 由 CGI 或 DHCP 客户端的 bash（以 开头#!/bin/bash，而不是开头）执行的脚本。#!/bin/sh
  • 受限制的 SSH 帐户，其 shell 为 bash。

该测试如何工作

它使用设置为环境变量值的bash -c :文字文本运行命令。() { :;}; echo VULNERABLEx

• :内置不执行任何操作；它用于需要非空命令的地方。

• bash -c :创建一个运行:和退出的 bash 实例。

  即使这样也足以触发漏洞。即使 bash 被调用以仅运行一个命令（并且该命令是无操作的），它仍然会读取其环境并将其内容以函数开头的每个变量解释() {为函数（至少那些名称是有效函数名称的变量）和运行它，以便定义函数。

  bash 的这种行为背后的意图是只运行一个函数定义，这使得一个函数可以使用，但实际上并不运行其中的代码。

• () { :;}是对调用时不执行任何操作的函数的定义。后面需要一个空格，{以便将{其解析为单独的标记。之前需要一个;或换行符}才能被接受为正确的语法。

  有关在 bash 中定义 shell 函数的语法的更多信息，请参见Bash 参考手册中的3.3 Shell 函数。但请注意，bash 使用（和识别）的语法作为有效的导出 shell 函数，它应该运行的定义更具限制性：

  1. 它必须以确切的字符串开头，并且在和() {之间恰好有一个空格。){
  2. 尽管 shell 函数偶尔会将其复合语句包含在( )而不是 中{ }，但它们仍会在{ }语法中导出。() (内容以代替开头的变量() {不会测试或以其他方式触发漏洞。

• bash应该在关闭后停止执行代码}。但是（除非打补丁）它没有！这是构成 CVE-2014-6271（“Shellshock”）的错误行为。

  ;结束定义函数的语句，允许读取后续文本并将其作为单独的命令运行。后面的文本;不必是另一个函数定义——它可以是任何东西。

• 在这个测试中，后面的命令;是echo VULNERABLE. 前面的前导空格echo什么都不做，只是为了可读性而存在。该echo命令将文本写入标准输出。的完整行为echo实际上有些复杂，但这在这里并不重要：echo VULNERABLE很简单。它显示文本VULNERABLE。

  由于echo VULNERABLE仅在 bash 未打补丁并在环境变量中的函数定义之后运行代码时才运行，因此此（以及许多其他类似的测试）是对安装的bash是否易受 CVE-2014-6271 攻击的有效测试。

其他函数解析错误（以及为什么该测试和类似的测试不检查它们）

在撰写本文时已发布的补丁以及上面描述和解释的用于检查漏洞的命令适用于称为 CVE-2014-6271 的非常严重的错误。此补丁和上述用于检查漏洞的命令均不适用于相关错误 CVE-2014-7169（也不应假定它们适用于可能尚未发现或披露的任何其他错误）。

错误CVE-2014-6271源于两个问题的组合：

1. bash 接受任意环境变量中的函数定义，并且
2. 这样做时，bash 会继续运行}函数定义的右大括号 ( ) 之后存在的任何代码。

在撰写本文时，已发布（并由许多下游供应商推出）的 CVE-2014-6271 的现有修复程序 - 即通过更新系统或手动应用现有补丁获得的修复程序 - - 是对2的修复。

但是在bash 的代码中存在其他错误的情况下， 1可能是许多其他解析错误的来源。我们知道至少还有一个这样的错误存在——特别是CVE-2014-7169。

此答案中提供的命令测试是否已使用 CVE-2014-6271 的现有（即第一个官方）修复程序修补已安装的 bash。它测试了该特定解析错误的漏洞：“GNU Bash 到 4.3 处理环境变量值中函数定义之后的尾随字符串 [...]”

这个特定的错误非常严重——可用的补丁确实修复了它——而 CVE-2014-7169 似乎不那么严重，但绝对仍然值得关注。

正如Stéphane Chazelas（Shellshock 错误的发现者）最近在对何时引入 shellshock (CVE-2014-6271) 错误的回答中解释的那样，完全修复它的补丁是什么？在Unix.SE上：

有一个补丁可以防止bash解释除函数定义之外的任何其他内容（https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html），这就是已应用于各种 Linux 发行版的所有安全更新。

然而，bash 仍然解释那里的代码，并且解释器中的任何错误都可能被利用。已经发现了一个这样的错误 (CVE-2014-7169)，尽管它的影响要小得多。所以很快就会有另一个补丁。

但如果这就是漏洞利用的样子......

在这里和其他地方，有些人问为什么x='() { :;}; echo VULNERABLE' bash -c :打印VULNERABLE（或类似的）应该被认为是令人震惊的。而且我最近看到了一种误解，即因为您必须已经具有交互式 shell 访问权限才能输入该特定命令并按 enter，所以 Shellshock 一定不是一个严重的漏洞。

尽管我听到的一些观点——我们不应该急于恐慌，NAT 路由器后面的桌面用户不应该为了从源代码构建 bash 而放弃生命——是非常正确的，这使漏洞本身感到困惑通过运行某些特定命令（例如此处提供的命令）对其进行测试的能力是一个严重的错误。

这篇文章中给出的命令是对以下问题的回答：“是否有一个简短的命令来测试我的服务器是否对 shellshock bash 错误安全？” 这不是回答“当真正的攻击者对我使用 shellshock 时会是什么样子？” 这不是对“某人必须做什么才能成功利用此漏洞？”这个问题的答案。（这也不是回答“如果我个人处于高风险中，是否有一个简单的命令可以从所有技术和社会因素中推断出来？”）

该命令是一个测试，以查看 bash 是否会以特定方式在任意环境变量中执行编写的代码。Shellshock 漏洞不是x='() { :;}; echo VULNERABLE' bash -c :. 相反，该命令（和其他类似命令）是一种诊断，可帮助确定一个人是否受到 Shellshock 的影响。

• Shellshock具有广泛的后果，尽管对于没有运行远程访问网络服务器的桌面用户来说，风险几乎可以肯定较小。（我认为我们目前还不知道的事情少了多少。）
• 相比之下，该命令 x='() { :;}; echo VULNERABLE' bash -c :完全无关紧要，除非它可用于测试 Shellshock（特别是对于 CVE-2014-6271）。

对于那些感兴趣的人，这里有一些资源，其中包含有关为什么认为此错误被认为是严重的信息以及为什么环境变量（尤其是在网络服务器上）可能包含能够利用该错误并造成伤害的不受信任的数据：

• 回复：CVE-2014-6271：通过 bash 远程执行代码
  （Florian Weimer，星期三，2014 年 9 月 24 日 17:03:19 +0200）
• 通过特制环境变量的 Bash 代码注入漏洞 (CVE-2014-6271、CVE-2014-7169)
• 如何利用 Shellshock Bash 漏洞的具体示例是什么？
• 新 Bash 漏洞的攻击场景
• CVE-2014-6271 Bash 漏洞示例
• kasperd对env x='() { :;};的回答 命令' bash 做，为什么它不安全？
• 新的 bash 漏洞利用 (shellshock) 的严重程度如何？

为了进一步说明这里的概念区别，请考虑两个假设：

1. 想象一下，如果x='() { :;}; echo VULNERABLE' bash -c :我没有建议作为测试，而是建议bash --version作为测试。（这实际上并不是特别合适，因为操作系统供应商经常将安全补丁向后移植到旧版本的软件。在某些系统上，程序提供给您的版本信息可能会使程序看起来容易受到攻击，而实际上它已经存在补丁。）

   如果bash --version建议运行测试，没有人会说，“但是攻击者不能坐在我的电脑前打字bash --version，所以我一定没问题！” 这是测试和正在测试的问题之间的区别。

2. 想象一下，如果发布了一条建议，表明您的汽车可能存在一些安全问题，例如安全气囊故障或在碰撞中起火，并且工厂演示已经进行了直播。没有人会说，“但我绝不会不小心将我的汽车开到或拖到 900 英里外的工厂，然后装上昂贵的碰撞假人并撞到混凝土墙上。所以我一定会没事的！” 这是测试和正在测试的问题之间的区别。

您可以通过在默认 shell 中运行以下行来检查您是否易受攻击，在许多系统上将是 Bash。如果你看到“busted”字样，那么你就处于危险之中。如果只有第二个命令打印“busted”，那么您的 bash 是易受攻击的，但该漏洞仅影响系统中显式调用 bash 的部分，而不影响运行默认 shell ( sh) 的部分。如果两个命令都没有打印“busted”，那么你的系统已经打了补丁。

env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
env X="() { :;} ; echo busted" bash -c "echo completed"

来源

修补后，您的系统可能仍然容易受到攻击：

env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

来源和另一个来源

如果您需要一种方法来一次检查同一子网上的多个服务器，您可以使用 Masscan 向所有服务器发送请求：https ://github.com/robertdavidgraham/masscan

可以在http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html找到示例配置文件：

target = 0.0.0.0/0 //CHANGE THIS TO THE PROPER SUBNET
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header[Cookie] = () { :; }; ping -c 3 209.126.230.74
http-header[Host] = () { :; }; ping -c 3 209.126.230.74
http-header[Referer] = () { :; }; ping -c 3 209.126.230.74
//change the above 3 Ip addresses to the IP of the machine you send it from.

易受攻击的机器会向您发送 ping 回复。根据作者的后续博文，可能需要进行一些配置。

您可以检查您的服务器将 CGI URL 提交到以下在线测试：

http://shellshock.iecra.org