Shellshock Bash 漏洞是如何发现的？

Question

为了让一些人放心，我没有通过观察漏洞发现该错误，我没有理由相信它在被披露之前就已经被利用了（尽管我当然不能排除这种可能性）。我也没有通过查看bash的代码找到它。

我不能说我清楚地记得我当时的想法。

这或多或少来自于我发现的一些软件的某些行为的一些反思危险的（行为，而不是软件）。那种行为会让你思考：这听起来不是一个好主意。

在本例中，我反思了 ssh 的常见配置，该配置允许传递来自客户端的未经清理的环境变量，前提是它们的名称以LC_.这个想法是为了让人们在ssh进入其他机器时可以继续使用自己的语言。这是一个好主意，直到您开始考虑本地化处理有多么复杂，特别是当 UTF-8 被纳入考虑范围时（并看到许多应用程序处理它的方式有多糟糕）。

早在 2014 年 7 月，我就已经报告了 glibc 本地化处理中的一个漏洞，该漏洞与该sshd 配置相结合，并且另外两个危险行为bash壳的允许（经过身份验证的）攻击者侵入 git 服务器，前提是他们能够在那里上传文件并bash用作 git unix 用户的登录 shell (CVE-2014-0475)。

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

AcceptEnv LC_*允许任何名称开头的变量LC_，我模糊地记得bash 导出函数（A危险的尽管有时有用的功能）正在使用名称类似的环境变量 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（可能还有很长的列表）来利用，并报告它（小心）。

Answer 1