Shellshock Bash 漏洞是如何发现的？

Question

由于此错误影响了如此多的平台，我们可能会从发现此漏洞的过程中了解到一些信息：它是 ?????? （尤里卡）时刻还是安全检查的结果？

由于我们知道 Stéphane 发现了 Shellshock 错误，其他人也可能知道这个过程，我们会对他如何找到这个错误的故事感兴趣。

Answer 1

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

我不能说我完全记得我当时的思路。

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

在这种情况下，我正在考虑 ssh 的常见配置，该配置允许从客户端传递未经消毒的环境变量，前提是它们的名称以LC_. 这个想法是为了让人们在ssh进入其他机器时可以继续使用他们自己的语言。一个好主意，直​​到您开始考虑本地化处理的复杂程度，尤其是当 UTF-8 被引入等式时（并看到它被许多应用程序处理得有多糟糕）。

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

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

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（可能还有很长的列表）并报告了它（仔细） .