如何找到Shellshock Bash漏洞？

由于此错误影响了这么多平台，因此我们可能会从发现此漏洞的过程中学到一些东西：是εὕρηκα（eureka）时刻还是安全检查的结果？

既然我们知道Stéphane发现了Shellshock错误，而且其他人也可能知道该过程，那么我们会对他如何找到该错误的故事感兴趣。

为了让大家放心，我没有通过观察漏洞发现漏洞，我没有理由相信它在被披露之前就已经被利用了（尽管我不能排除它）。我也没有通过查看bash的代码找到它。

我不能说我当时确实记得我的思路。

这或多或少来自对我认为危险的某些软件（行为，而不是软件）的某些行为的反思。一种使您思考的行为：听起来不像是个好主意。

在这种情况下，我在思考ssh的通用配置，该配置允许传递未经客户端明确处理的环境变量，前提是它们的名称以开头LC_。这样做的目的是使人们在ssh进入其他计算机时可以继续使用自己的语言。在开始考虑本地化处理的复杂性之前，这是一个好主意，尤其是当将UTF-8引入方程式（并查看许多应用程序对它的处理程度）时。

早在2014年7月，我在此前已经报道在glibc的本地化处理一个漏洞，它与组合sshd 配置，和其他两个危险行为的的bash外壳 允许（验证），攻击者入侵到git的服务器提供的，他们能够有上传文件和bash使用作为git unix用户的登录外壳程序（CVE-2014-0475）。

我认为，bash用作通过ssh提供服务的用户的登录shell 可能是一个坏主意，因为它是一个相当复杂的shell（当您需要的只是解析一个非常简单的命令行时），并且继承了大多数错误的设计的ksh。由于我已经确定了bash在该上下文中使用的一些问题（用于解释ssh ForceCommand），所以我想知道那里是否还有更多问题。

AcceptEnv LC_*允许任何名称以开头的变量，LC_而我模糊地回忆起bash 导出的函数（虽然是有用的功能，这是一个危险的时刻）正在使用名称类似的环境变量， myfunction()并且想知道那里是否没有有趣的东西。

我将其驳回的理由是，最糟糕的事情是重新定义一个被称为命令的命令LC_something ，由于这些命令名不是现有的命令名，所以这实际上不是问题，但是随后我开始怀疑如何bash 导入这些环境变量。

LC_foo;echo test; f()例如，如果变量被调用怎么办？所以我决定仔细看看。

A：

$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() {  :
}

表明我的记忆是错误的，该变量不叫myfunction()，但myfunction（和它的 值与启动()）。

快速测试：

$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'

证实了我的怀疑，即未清除变量名，并且在启动时对代码进行了评估。

更糟的是，更糟的是，该值也没有被消毒：

$ env 'foo=() { :;}; echo test' bash -c :
test

这意味着任何环境变量都可以是向量。

到那时，我意识到问题的严重性，并确认它也可以通过HTTP（HTTP_xxx/ QUERYSTRING... env vars），其他类似邮件处理服务，后来的DHCP（可能还有很长的列表）加以利用，并认真地进行了报告。 。