shellshock（CVE-2014-6271 / 7169）漏洞是什么时候引入的，什么补丁可以完全解决该问题？

  VAR=() { ignored; }; /bin/id

#1 楼

TL; DR

shellshock漏洞已完全修复，在bash-2.05b分支上的


：2.05b.10及更高版本（包括补丁10）
在bash-3.0分支上：3.0.19及更高版本（包括补丁19）
在bash-3.1分支上：3.1.20及更高版本（包括补丁20）
在bash-3.2上分支：3.2.54及更高版本（包括补丁54）
在bash-4.0分支上：4.0.41及更高版本（包括补丁41）
在bash-4.1分支中：4.1.14及更高版本（
在bash-4.2分支上：4.2.50及更高版本（包括补丁50）
在bash-4.3分支上：4.3.27及更高版本（包括补丁27）

如果您的bash显示较旧的版本，则您的操作系统供应商可能仍在对其进行修补，因此最好进行检查。

如果：

env xx='() { echo vulnerable; }' bash -c xx

显示“脆弱”，您仍然很脆弱。那是唯一相关的测试（bash解析器是否仍暴露于任何环境变量中的代码）。

详细信息。

该错误在于的初始实现该功能的导出/导入功能由Brian Fox在1989年8月5日引入，并在一个月后的bash-1.03中首次发布，当时bash并未得到广泛使用，在此之前，安全性一直是人们关注的重点，而HTTP和Web或Linux甚至都存在。

从1.05中的ChangeLog：

Fri Sep  1 18:52:08 1989  Brian Fox  (bfox at aurel)

       * readline.c: rl_insert ().  Optimized for large amounts
         of typeahead.  Insert all insertable characters at once.

       * I update this too irregularly.
         Released 1.03.
[...]
Sat Aug  5 08:32:05 1989  Brian Fox  (bfox at aurel)

       * variables.c: make_var_array (), initialize_shell_variables ()
         Added exporting of functions.

gnu中的某些讨论那时的.bash.bug和comp.unix.questions也提到了该功能。

很容易理解它的实现方式。

bash导出env vars中的函数像

foo=() {
  code
}

导入时，要做的就是解释用空格代替=…只是不要盲目地解释它。

它在bash中也被打破了（相反对于Bourne shell），标量变量和函数具有不同的名称空间。其实如果您有

foo() { echo bar; }; export -f foo
export foo=bar

bash会很高兴将两者都放入环境中（是的，具有相同的变量名），但是许多工具（包括许多shell）不会传播它们。

有人还认为bash应该使用BASH_命名空间前缀为此，因为env var仅在bash与bash之间相关。 rc为相似的功能使用了fn_前缀。

一种更好的实现方式是将所有导出变量的定义放在一个变量中，例如：

BASH_FUNCDEFS='f1() { echo foo;}
  f2() { echo bar;}...'

仍然需要清理，但至少不能比$BASH_ENV或$SHELLOPTS更具可利用性。

有一个修补程序可以阻止bash解释除以下内容以外的任何内容其中的功能定义（https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html），并且该定义已应用于各种Linux的所有安全更新中发行版。

但是，bash仍在其中解释代码，并且解释器中的任何错误都可以被利用。尽管已经发现了一个这样的错误（CVE-2014-7169），但其影响要小得多。因此，很快就会有另一个补丁。

直到进行了一项强化的修复，以防止bash解释任何变量中的代码（例如，使用上述BASH_FUNCDEFS方法），我们才能确定我们是否不受bash解析器中的错误的影响。而且我相信迟早会发布这样的强化修复程序。

编辑2014-09-28

解析器中发现了两个其他错误（CVE-2014 -718 {6,7}）（请注意，大多数外壳在解析器中必然会遇到一些漏洞，对于极端情况，如果解析器没有暴露于不受信任的数据中就不会担心）。

虽然所有3个bug 7169、7186和7187均已在以下修补程序中修复，但Red Hat推动了该修复程序。在他们的补丁程序中，他们改变了行为，以便将功能导出到称为BASH_FUNC_myfunc()的变量中，这或多或少地取代了切特的设计决定。

切特后来发布了该补丁程序，作为正式的上游bash补丁程序。

该加固补丁或其变种现在可用于大多数主要的Linux发行版，并最终将其发布到Apple OS / X。

现在，该漏洞使使用解析器的任何环境变量都无需担心。通过该向量包括解析器中的其他两个漏洞（CVE-2014-627 {7,8}），该漏洞后来由MichałZalewski（CVE-2014-6278几乎与CVE-2014-6271一样严重）披露，在大多数人心存感激之后曾经有时间安装强化补丁

解析器中的错误也将得到修复，但是由于解析器不再那么容易暴露于不受信任的输入，因此它们不再是一个大问题。

请注意，虽然安全漏洞已得到修复，但我们很可能会看到帽子区。 CVE-2014-6271的初始修复已破坏了向后兼容性，因为它停止了导入名称为.或:或/的函数。那些仍然可以通过bash声明，尽管这会导致行为不一致。因为通常使用名称为.和:的函数，所以修补程序很可能会恢复以至少接受来自环境的函数。

为什么以前没有找到它？

这也是我想知道的事情。我可以提供一些解释。

首先，我认为，如果安全研究人员（并且我不是专业的安全研究人员）专门在寻找bash中的漏洞，他们可能会找到它。 。

例如，如果我是一名安全研究人员，我的方法可能是：


查看bash从何处获取输入以及它的作用。环境显然是一个环境。
看看bash解释器的调用位置和数据。再次，它会脱颖而出。
当bash为setuid / setgid时，导入功能的导入是禁用的功能之一，这使它看起来更加明显。

现在，我怀疑没有人认为bash（解释器）是一种威胁，或者威胁可能以这种方式发生。

bash解释器不是要处理不受信任的输入。

通常从安全的角度仔细研究Shell脚本（而不是解释器）。 shell语法非常笨拙，编写可靠脚本的警告很多（我见过别人或其他人提到过split + glob运算符，或者为什么要引用变量吗？），在处理该脚本的安全漏洞中很常见不受信任的数据。

这就是为什么您经常听到不应该编写CGI Shell脚本或在大多数Unices上禁用setuid脚本的原因。或者在处理世界可写目录中的文件时应格外小心（例如，请参阅CVE-2011-0441）。

重点在于外壳脚本，而不是解释器。

您可以通过eval或.或在用户提供的文件上调用外壳解释器，以将外壳解释器暴露给不受信任的数据（将外部数据作为外壳代码进行解释），但是您无需在bash中存在漏洞即可利用它。很明显，如果您要传递未经处理的数据供外壳程序解释，它将解释它。

因此，该外壳程序在受信任的上下文中被调用。它提供了固定的脚本来解释，并且经常（因为编写可靠的脚本非常困难）来处理固定的数据。

例如，在Web上下文中，shell可能以类似的方式被调用：

popen("sendmail -oi -t", "w");

这可能出什么问题？如果设想有问题，那是关于送入该sendmail的数据，而不是该shell命令行本身是如何解析的或向该shell馈入了什么额外的数据。您没有理由要考虑传递给该Shell的环境变量。并且，如果您这样做了，您就会意识到，所有的环境变量都以“ HTTP_”开头，或者是众所周知的CGI环境变量，例如SERVER_PROTOCOL或QUERYSTRING，它们与Shell或sendmail都没有关系。

在特权提升环境中（例如，运行setuid / setgid或通过sudo时），通常会考虑环境，并且过去存在很多漏洞，同样不是针对shell本身，而是针对诸如sudo之类的提升特权的事物（请参阅参考资料）。例如CVE-2011-3628）。

例如，当setuid或由setuid命令调用时，bash不信任环境（例如，调用助手的mount）。特别是，它将忽略导出的函数。

sudo确实清除了环境：默认情况下全部清除，但白名单除外；如果不配置，则至少清除黑名单，其中一些已知会影响Shell或另一个（例如PS4，BASH_ENV，SHELLOPTS ...）。它还会将内容以()开头的环境变量列入黑名单（这就是CVE-2014-6271不允许通过sudo进行特权升级的原因）。

同样，这适用于环境不能存在的环境。可信：任何具有任何名称和值的变量都可以由恶意用户在该上下文中设置。这不适用于Web服务器/ ssh或利用CVE-2014-6271的所有媒介，在这些媒介中控制了环境（至少控制了环境变量的名称...）

阻塞像echo="() { evil; }"这样的变量很重要，但不要阻塞HTTP_FOO="() { evil; }"，因为任何shell脚本或命令行都不会将HTTP_FOO称为命令。而且apache2永远不会设置echo或BASH_ENV变量。

很明显，某些环境变量应在某些情况下根据其名称被列入黑名单，但没有人认为它们应被列入黑名单。根据其内容（sudo除外）。换句话说，没有人认为任意的环境变量可以作为代码注入的载体。

关于添加功能时进行广泛的测试是否可以抓住它，我想这不太可能。

测试功能时，即测试功能。功能正常。如果您在一个bash调用中导出函数，则可以在另一个调用中导入。当导出具有相同名称的变量和函数时，或者当导入的函数与导出时所使用的语言环境不同时，进行彻底的测试可能会发现问题。

但是能够发现漏洞，这不是您必须要做的功能测试。安全性本来应该是主要关注点，并且您不必测试功能，但要测试其机制和滥用方式。

开发人员并不需要（特别是在1989年）通常他们会后悔，外壳开发人员可能会被认为自己的软件不太可能被网络利用。

#2 楼

根据NIST的NVD数据库（http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271），从1.14.0版本开始的所有bash版本都容易受到攻击。
RedHat在9月14日发现了该错误。
Mr.Ramey（bash维护者）于2014年9月26日发布的补丁修复了CVE-2014-7169错误。
应用这些补丁和所有以前的补丁到相应的bash来源：

http://ftp.gnu.org/pub/gnu/bash/bash-2.05b-patches/bash205b-010
http：//ftp.gnu .org / pub / gnu / bash / bash-3.0-patches / bash30-019
http://ftp.gnu.org/pub/gnu/bash/bash-3.1-patches/bash31-020
http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-054
http://ftp.gnu.org/pub/gnu/bash/bash-4.0-补丁/ bash40-041
http://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-014
http://ftp.gnu.org/pub/ gnu / bash / bash-4.2-patches / bash42-050 ​​
http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-027


bash中的其他漏洞

https://access.redhat.com/security/c ve / CVE-2014-7186
https://access.redhat.com/security/cve/CVE-2014-7187


更多有关错误（由mikeserv提供）
来源：http://www.linuxmisc.com/12-unix-shell/e3f174655d75a48b.htm

1994年，Chet Ramey将其描述为早于旧的POSIX。无论如何，2个规范指定了导出的功能。或者，至少，他描述了bash机制是这样做的-无论当时是否有缺陷，现在我还不知道。他还讨论了该线程中rc的函数导出。