Django 博客上发布了有关此事的安全公告：

此问题不会直接影响 Django，但会影响 Django 的大多数用户。

任何通过 CGI 或类 CGI 接口（包括 WSGI）提供流量的 Web 服务器都应立即升级其 Bash 版本。

更新 bash，这个特定的问题就消失了。

但是，如果您想知道在此之前您是否存在漏洞，将会有特定于应用程序的路径添加到通用漏洞中（直到 bash 被修补 - 然后可能会有新的非 bash 漏洞在以后以相同的模式被发现）。

具体问题在于允许攻击者控制环境变量。如果攻击者能够远程获取设置为函数定义的环境变量，然后是立即命令；攻击者可以等待一些完全不相关的命令被 bash 执行。它是哪个 bash 程序，或者参数是否经过验证（或硬编码等）都没有关系。

具体来说，bash 与任何其他程序一样有一个主入口点，并且它具有以下签名：

int main(int argc, char** argv, char** arge); //bash's main entry point

这个 main 函数作为调用 exec 的内部细节被调用。如果没有事先清理 arge，则 bash 的 main 将尽职尽责地执行 bash shell 应该执行的操作。其中之一是解析环境。

我们都有擦洗 argc 和 argv 以保持清洁的习惯。但是大多数人完全忽略了 arge 中的内容。因此，如果远程套接字告诉进程设置环境变量（即：HTTP_COOOKIE），则 arge 的某些条目具有该值。假设 arge[42] 有一个值：

HTTP_COOKIE=() { :; }; /usr/bin/eject

然后bash的main看到字符串值有开/关括号，猜测这一定是一个函数定义。所以它尽职尽责地将 HTTP_COOKIE 定义为一个函数，并在它之后执行立即命令。

所以，如果环境有这个变量，那么还没有发生任何不好的事情。但是你可以很容易地调用没有明显执行 bash 的无害 Python 代码。这就是你所看到的：

Licensing().check()

也许您的公司使用了一个检查许可证的二进制文件，而您调用了此函数（您不知道它的作用）。但是说它最终的作用是这样的（解决到 C 实现）：

//There are no arguments to this program so this is "safe"
execl("/bin/bash", "bash", "-c", "licensingWrapper", (char*)0);

然后bash启动...

//This is bash's main function
int main(int argc, char** argv, char** arge) {
    ....
    parseEnvironment(arge);  //!!!!
    ....
}

然后在 parseEnvironment 中，在 arge[42] 处，它会看到一些名为“HTTP_COOKIE”的变量并对其进行解析。bash 对这个变量的用途一无所知，但它认为它是一个函数定义，带有一些立即执行的命令；并且做到了。这个环境解析只是让 shell 准备好执行任何 argv 说要执行的标准先决条件。

如果您对此进行更深入的思考，那只是不清理输入的另一种情况。没有人清理环境输入。更糟糕的是，环境变量会根据它们被传递到的内容（bash、sh、java ......）而得到不同的解释。因此，如果您有一个通用函数来清理环境，它将特定于您希望稍后运行的 exec 类型。

int main(int argc, char** argv, char** arge) {
    BOOL isClean = TRUE;
    isClean &= cleanseEnvironment(arge, BASIC_SANITY);
    isClean &= cleanseEnvironment(arge, BASH_RULES);
    if(isClean) {
        parseEnvironment(arge);
    }
    else {
        return -EBADENVIRONMENT;
    }
    ...
}

所以我会高度怀疑环境变量被设置为攻击者污染的值。然后简单地假设一些你没有想到的 shell 稍后会在那个环境中执行。如果您能证明 bash 最终被执行，那么您就有一个明显的问题。但它很容易成为间接路径，例如 tcl 被执行，然后 tcl 导致 bash 被调用。