Bash Shellshock-为什么允许注入环境变量？

关于shellshock漏洞，有两件事我不了解：

为什么允许向未经验证的连接注入环境变量？那有什么用

哪些实际服务提供了注入变量的能力

有什么想法吗？

1）该漏洞是一个实现错误。从不受信任的源向环境变量中注入指令不是故意允许的——这就是为什么它是一个bug

---

2） 有关如何利用漏洞的示例，请参阅。

环境变量是与子进程通信的一种非常常见的方式。您可能会问“为什么允许将参数传递给子进程？”当然，使用环境变量时需要更加谨慎，因为某些环境变量（

PATH

）会影响某些系统调用的语义。因此，通常的惯例是将可从不可信输入设置的环境变量限制为一组已知名称

例如，CGI协议——它使用环境变量来传递有关HTTP请求的信息——将自身限制为一组环境变量名，这些环境变量名可以松散地描述为，加上名称以字符

HTTP\uuu

开头的任意环境变量

虽然CGI可能拥有最多的用户输入环境变量，但这种技术非常常见。一个公认的例子是使用

术语

来定义远程终端的终端类型，但还有更多

环境变量，如命令行参数，需要谨慎对待，有时还需要设置障碍。例如，

/bin/env

实用程序提供了一种机制来清理给定给可执行文件的环境；如果环境不可信，那么这很有用；如果可执行文件以提升的权限运行，那么这很重要

---

除了特定情况（如

PATH

），任何应用程序都不应依赖于干净的环境变量。在不首先检查环境变量的有效性的情况下，根据环境变量的值做一些事情，与用户提供的数据的任何其他未经验证的使用一样，都是一个错误。（q.v.SQL注入攻击）这就是我们这里的问题：一个简单明了的bug。这些事情经常发生。我们并不完美。（这个bug已经存在了二十多年，显然没有人注意到这一事实，至少是有趣的。）

欢迎来到Stack Overflow。请尽快阅读这一页。这两个问题（或两部分问题）确实有点宽泛。另外，第二个问题的答案很容易在网上找到。您当然应该阅读问题和答案，看看：一个观察（反问题）：shell如何知道连接是否被验证？问题不是环境变量本身；假设环境变量的值只包含函数声明，而不验证该假设，则该环境变量的值是

eval

ed。