apt-get update; apt-get upgrade -y。我不确定我的/etc/apt/sources.list在所有这些系统上是否足够好。我想快速地再次检查每个系统，理想情况下是使用单行shell命令。是否存在这样的单行shell命令，如果存在，它是什么？
请注意，此问题主要与CVE-2014-6271有关。
#1 楼
我的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还是其他外壳。该漏洞位于bash特定的功能中，并且其他shell（例如dash和ksh）不受影响。您可以通过使用sh而不是bash运行与上述相同的测试来测试默认Shell：x='() { :;}; echo VULNERABLE' sh -c :
如果看到错误消息，则您的系统bash具有修补的bash并且不易受到攻击。
如果看到
VULNERABLE，则系统的默认外壳为bash，并且所有攻击媒介都值得关注。如果没有输出，则系统的默认外壳为不是bash，只有使用bash的系统部分容易受到攻击。检查：
从CGI或DHCP客户端由bash（以
#!/bin/bash开头，而不是#!/bin/sh开头）执行的脚本。shell为bash的受限制的SSH帐户。
>
此测试的工作方式
它运行命令
bash -c :，并将文本文本() { :;}; echo VULNERABLE设置为环境变量x的值。 br /> 内置的
:不执行任何操作；它用于需要非空命令的地方。bash -c :创建一个运行:并退出的bash实例。这足以使漏洞得以解决。触发。即使调用bash仅运行一个命令（并且该命令是no-op），它仍会读取其环境并将其内容以
() {开头的每个变量解释为一个函数（至少那些名称为有效函数名的变量）并运行它以便定义函数。bash行为的目的是仅运行一个函数定义，这使一个函数可用，但实际上并未在其中运行代码。
() { :;}是函数的定义，该函数在被调用时不执行任何操作。 {之后需要一个空格，以便将{解析为一个单独的令牌。要在;之前接受}或换行符，它才能被接受作为正确的语法。但是请注意，bash作为有效的导出shell函数使用（并识别）的语法应更严格地执行其定义，该语法必须严格限制： () {和)之间有一个空格。尽管shell函数偶尔将其复合语句括在
{中而不是( )中，但它们仍以{ }语法导出。内容以{ }而不是() (开头的变量将不会测试或触发漏洞。 bash在关闭() {后应停止执行代码。但是（除非打补丁）没有！这是构成CVE-2014-6271（“ Shellshock”）的错误行为。}结束定义函数的语句，从而允许后续文本作为单独的命令读取和运行。而且;之后的文本不必是另一个函数定义-可以是任何东西。在此测试中，
;之后的命令是;。 echo VULNERABLE之前的前导空格不执行任何操作，而仅仅是为了便于阅读。 echo命令将文本写入标准输出。 echo的完整行为实际上有点复杂，但这在这里并不重要：echo很简单。它显示文本echo VULNERABLE。由于VULNERABLE仅在未修补bash且在环境变量中的函数定义之后运行代码时才运行，因此（以及与之类似的许多其他测试）是是否或不进行测试的有效测试并非已安装的echo VULNERABLE容易受到CVE-2014-6271的攻击。<br /> 其他功能解析错误（以及为什么该测试以及类似的测试无法进行检查） br />
截至本文撰写时已发行的补丁以及上面介绍和解释的用于检查漏洞的命令适用于非常严重的bug，称为CVE-2014-6271。此修补程序或上述检查漏洞的命令均不适用于相关的漏洞CVE-2014-7169（也不应假定它们适用于可能尚未发现或公开的任何其他漏洞）。 /> CVE-2014-6271错误源于两个问题的组合：
bash在任意环境变量中接受函数定义，而在执行此操作时
，bash会继续运行函数定义的右大括号（
bash）之后存在的任何代码。撰写本文时，已发布（并推出）CVE-2014-6271的现有修补程序由许多下游供应商提供）-也就是说，通过更新系统或手动应用现有补丁获得的修复程序-是针对2的修复程序。
但是在bash代码中存在其他错误的情况下，1可能是许多其他解析错误的来源。而且我们知道至少存在一个其他此类错误-特别是CVE-2014-7169。第一官方）针对CVE-2014-6271的修复。它测试了针对该特定解析错误的漏洞：“ GNU Bash 4.3通过过程在环境变量的值中定义了函数定义后的尾随字符串[...]”
该特定错误非常严重，而且可用的修补程序确实可以解决此问题-尽管CVE-2014-7169似乎不太严重，但仍然值得关注。
正如StéphaneChazelas（Shellshock bug的发现者）最近在回答中解释的那样到什么时候引入了shellshock（CVE-2014-6271）错误的，什么补丁可以完全解决该问题？在Unix.SE上：
有一个补丁可以阻止
}解释那里的函数定义以外的其他内容（https：//lists.gnu .org / archive / html / bug-bash / 2014-09 / msg00081.html），
，这是已应用于各种Linux发行版的所有安全更新中的一种。
但是，bash仍然解释其中的代码，并且
解释器中的任何错误都可以被利用。已经发现了这样的错误之一
（CVE-2014-7169），尽管其影响要小得多。所以很快就会有另一个补丁。
但是如果这就是漏洞利用的样子...
有些人，无论在这里还是在其他地方，都问为什么应将
bash打印x='() { :;}; echo VULNERABLE' bash -c :（或类似的东西）视为令人震惊的问题。而且我最近看到一种误解，因为您必须已经具有交互式外壳程序访问权限才能键入该特定命令并按Enter，所以Shellshock一定不是一个严重的漏洞。尽管我已经听到一些情绪表达了我们不要急于慌张，但NAT路由器后面的台式机用户不应搁置生命来从源代码构建bash，这是相当正确的，使漏洞本身变得混乱能够通过运行某些特定命令（例如此处显示的命令）进行测试是一个严重的错误。
本文中给出的命令是对以下问题的回答：“是否存在测试我的服务器是否对shellshock bash错误安全的简短命令？”这不是对“当一个真正的攻击者对我使用shellshock时会是什么样？”的答案。但这并不是对以下问题的答案：“要成功利用此bug，必须做什么？” （这也不能回答“如果我个人处于高风险状态，是否有一个简单的命令可以从所有技术和社会因素中推断出？”）
该命令是一种测试，旨在查看bash是否将执行以特定方式在任意环境变量中编写的代码。 Shellshock漏洞不是
VULNERABLE。相反，该命令（和其他类似的命令）是一种诊断方法，可以帮助确定一个命令是否受Shellshock的影响。Shellshock会产生广泛的后果，尽管确实如此对于没有运行可远程访问的网络服务器的台式机用户来说，风险几乎可以肯定地降低。 （到目前为止，我不知道我们知道多少东西。）
相比之下，命令
x='() { :;}; echo VULNERABLE' bash -c :完全无关紧要，只是它对于测试Shellshock（特别是CVE-2014-6271）有用）。对于那些感兴趣的人，这里有一些资源，其中包含有关为什么将此bug视为严重错误以及为什么环境变量（尤其是网络服务器上的环境变量）可能包含能够利用该bug的不受信任的数据的信息。造成伤害：
回复：CVE-2014-6271：通过bash远程执行代码
（Florian Weimer，Wed，24 Sep 2014 17:03:19 +0200）
通过特制环境变量创建的Bash代码注入漏洞（CVE-2014-6271，CVE-2014-7169）
如何利用Shellshock Bash bug的一个具体示例是什么？
新攻击实例Bash漏洞
CVE-2014-6271 Bash漏洞示例
kasperd对env x ='（）{：;}的作用的回答命令'bash可以做什么，为什么它不安全？
新的bash攻击（shellshock）的严重性是什么？ ：
想象一下，如果我不是建议
x='() { :;}; echo VULNERABLE' bash -c :作为测试，而是建议x='() { :;}; echo VULNERABLE' bash -c :作为测试。 （这实际上不是特别合适，因为OS供应商经常将安全补丁移植到较旧的软件版本。程序在某些系统上可以为您提供的版本信息可以使该程序看起来很容易受到攻击，而实际上却是易受攻击的。 如果建议通过运行
bash --version进行测试，没有人会说：“但是攻击者不能坐在我的计算机上并键入bash --version，所以我必须没事！”这就是测试和要测试的问题之间的区别。想象一下，如果发布了一项建议，建议您的汽车可能存在一些安全问题，例如安全气囊故障或在碰撞中爆炸，而且工厂的示威游行已经流传了。没有人会说：“但我绝不会无意中开车或拖我的车到工厂900英里，并把它装上一个昂贵的防撞假人，然后撞到混凝土墙上。所以我必须没事！”这是测试与要测试的问题之间的区别。
评论
嗯，但是如果我可以运行bash，那么我是否可以在系统上执行任意命令？这个漏洞如何？
– Ajedi32
2014-09-25 14:08
@ Ajedi32 x ='（）{：;}; echo VULNERABLE'bash -c：用于测试您的bash是否已打补丁的测试。 CVE-2014-6271根本就是一个漏洞，原因在于它可以给任何可以设置某些环境变量值的人（在bash随后将使用该变量集运行的条件下）运行任意命令。环境变量通常用于在流程之间传递未经消毒的，用户提供的数据。例如，通常可以通过HTTP利用此漏洞。请参阅seclists.org/oss-sec/2014/q3/650，“到目前为止，对CGI脚本的HTTP请求已被识别为主要攻击媒介”。
– Eliah Kagan
2014-09-25 14:31
@JakeGould关于此漏洞的最糟糕的事情是，要利用它，您根本不需要拥有帐户。即使（例如）您的Web服务器在严格受限的用户帐户下运行，对于攻击者而言，能够以该受限用户身份运行任意命令，从而完全控制您的Web服务器（甚至更多），将是非常糟糕的。请参阅此处的说明。测试漏洞的最便捷方法并不总是与在野外利用该漏洞的最具破坏性的方法相同。
– Eliah Kagan
2014-09-25 15:36
@JakeGould没有一个程序是“标准的Unix shell”。不同的OS对/ bin / sh使用不同的shell。在GNU / Linux上，sh通常是其他外壳程序的链接或副本。在Ubuntu和Debian中，破折号提供了sh，尽管bash几年前就这样做了。在某些操作系统上，sh仍然不起作用。 （我相信Slackware是一个例子，尽管我最近没有使用过。）快速的网络搜索或Wikipedia可以使您摆脱误解，并使我从虚假的无知指控中摆脱出来。
– Eliah Kagan
2014-09-25 17:12
@ user53029 CVE-2014-6271的已发布修补程序并未修复导致其潜在的设计缺陷，因此bash必须从环境中正确解析函数定义，否则将遭受潜在的安全性错误。从这个意义上说，修复是不完整的。但这确实（就已知而言）完全修复了在函数定义之后执行尾随代码的错误。因此，将CVE-2014-7169视为一个单独的漏洞在很大程度上是有意义的。 6271的补丁程序和此答案中的用于确定该补丁程序是否有效应用的测试不会针对7169进行测试。我已经详细介绍了此答案。
– Eliah Kagan
2014年9月25日20:07在
#2 楼
您可以通过在默认外壳程序中运行以下几行（在许多系统上为Bash）来检查是否容易受到攻击。如果看到“被破坏”一词，则表示您处于危险之中。如果仅第二个命令打印“已删除”，则您的bash容易受到攻击，但是该漏洞仅影响系统中显式调用bash的部分，而不影响运行默认Shell（sh）的部分。如果两个命令均未打印出“被破坏”，则说明您的系统已打补丁。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 :("
来源和另一来源
评论
我不确定应该使用哪种bash来完成bash不会：两者都运行在PATH中最先出现的bash，而且好像env不需要完全限定的名称。 （此外，您根本不需要环境。）
– Eliah Kagan
2014-09-25 12:41
@BadSkillz，您能否在env X ='（）{（a）=> \'sh -c“ echo date”;中添加一些说明？猫回声？那应该做什么或告诉我什么？
–kqw
2014-09-25 13:18
@Eliah，如果您能提出一个更好的答案，那就太好了。
–kqw
2014-09-25 13:18
哪种bash可能使您摆脱限制外壳程序命令路径文字的有效输入。
–zedman9991
2014-09-25 13:19
@KasperSouren，我认为它只是演示了bash函数解析中的一个错误，如此处所述...因此，这不是有效的bash语法。
– 0x80
2014-09-25 13:30
#3 楼
如果您需要一种方法来一次检查同一子网中的多个服务器，则可以使用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.
容易受到攻击的计算机将向您发送回信。根据作者的后续博客文章，可能需要一些配置。
评论
如何仅检查一台服务器？
–CharlesB
2014年9月26日上午10:30
@CharlesB只是远程连接到服务器并执行此页面上的oneliners之一。或使用子网掩码/ 32输入服务器的完整IP。
– Nzall
2014-09-26 10:45
谢谢;无法编辑它，但它必须是target-ip而不是target。如果我测试路由器，则无法检测到ping命令...是否还有另一条命令来证明该漏洞利用
–CharlesB
2014年9月26日上午10:57
SSH进入路由器，然后执行Eliah Khan在他的回答中建议的操作。您需要直接通过路由器终端执行此操作。
– Nzall
2014年9月26日上午11:06
我没有SSH访问权限，它是我们ISP的密闭盒。所以没办法检查吗？
–CharlesB
2014-09-26 11:40
#4 楼
您可以检查您的服务器是否向以下在线测试提交了CGI URL：http://shellshock.iecra.org
#5 楼
我编写了一个快速测试，可以打印“易受攻击”或“不易受攻击”：env x='() { :;}; echo vulnerable; exit;' bash -c 'echo not vulnerable' 2>/dev/null
如果您的bash版本易受攻击，它还会返回退出代码2。 ，如果您想将其用作脚本的一部分。
评论
已在3.2.51（1）-发行版（x86_64-apple-darwin13）和3.2.53（1）-发行版（x86_64-apple-darwin13）中进行了测试。
– colevk
2014年9月27日在0:12
#6 楼
您可以尝试ShellShocker，它是一个CLI实用程序，可以按以下方式检查CGI脚本：python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-cgi.cgi
评论
bash --version该错误影响bash的版本，包括4.3及以下版本。@raz检查bash版本没有用（除了4.3之后的版本（尚不存在）不会受到影响）。大多数系统将通过修补漏洞（通常通过应用发行版的正常更新过程）来修复漏洞，而不是通过升级到bash的全新版本（同样不存在）来修复漏洞。
@Gilles bash --version将报告类似4.3.25的版本号（该补丁程序修复了最初的（尽管不是完整的）Shell Shock漏洞）。没有理由认为补丁程序级别的发行版比将来的某些4.4版本完全不能解决问题。
@chepner ...这就是检查版本号无用的原因。在大多数发行版中，修复漏洞的升级不会更改版本号。易受攻击的版本和固定的版本具有相同的版本号。您不能使用它来判断漏洞是否存在。
如果我的发行版正在修补代码而根本没有增加版本号，我会感到有些沮丧。