Bash 中的 Shellshock 漏洞背后的行为是记录在案还是有意为之? [英] Is the behavior behind the Shellshock vulnerability in Bash documented or at all intentional?

问题描述

最近的一个漏洞，CVE-2014-6271，关于 Bash 如何解释环境变量 被披露.该漏洞利用 Bash 将一些环境变量声明解析为函数定义，然后继续执行定义后的代码:

A recent vulnerability, CVE-2014-6271, in how Bash interprets environment variables was disclosed. The exploit relies on Bash parsing some environment variable declarations as function definitions, but then continuing to execute code following the definition:

$ x='() { echo i do nothing; }; echo vulnerable' bash -c ':'
vulnerable

但是我不明白.我在 Bash 手册中找不到任何关于将环境变量解释为函数的内容(除了继承函数，这是不同的).事实上，一个正确命名的函数定义只是被视为一个值:

But I don't get it. There's nothing I've been able to find in the Bash manual about interpreting environment variables as functions at all (except for inheriting functions, which is different). Indeed, a proper named function definition is just treated as a value:

$ x='y() { :; }' bash -c 'echo $x'
y() { :; }

但是一个腐败的人什么也不打印:

But a corrupt one prints nothing:

$ x='() { :; }' bash -c 'echo $x'

$ # Nothing but newline

损坏的函数没有命名，所以我不能直接调用它.这个漏洞是一个纯粹的实现错误，还是这里有一个我看不到的预期功能?

The corrupt function is unnamed, and so I can't just call it. Is this vulnerability a pure implementation bug, or is there an intended feature here, that I just can't see?

根据 Barmar 的评论，我假设函数的名称是参数名称:

Per Barmar's comment, I hypothesized the name of the function was the parameter name:

$ n='() { echo wat; }' bash -c 'n'
wat

我可以发誓我以前尝试过，但我想我没有足够努力.现在可以重复了.下面是更多测试:

Which I could swear I tried before, but I guess I didn't try hard enough. It's repeatable now. Here's a little more testing:

$ env n='() { echo wat; }; echo vuln' bash -c 'n'
vuln
wat
$ env n='() { echo wat; }; echo $1' bash -c 'n 2' 3 -- 4

wat

...所以显然在漏洞利用执行时没有设置参数.

…so apparently the args are not set at the time the exploit executes.

无论如何，我的问题的基本答案是，是的，这就是 Bash 实现继承函数的方式.

Anyway, the basic answer to my question is, yes, this is how Bash implements inherited functions.

推荐答案

这似乎是一个实现错误.

This seems like an implementation bug.

显然，导出函数在 bash 中的工作方式是它们使用特殊格式的环境变量.如果导出函数:

Apparently, the way exported functions work in bash is that they use specially-formatted environment variables. If you export a function:

f() { ... }

它定义了一个环境变量，如:

it defines an environment variable like:

f='() { ... }'

可能发生的情况是，当新 shell 看到一个值以 () 开头的环境变量时，它会在变量名前面加上并执行结果字符串.错误在于这包括在函数定义之后执行任何.

What's probably happening is that when the new shell sees an environment variable whose value begins with (), it prepends the variable name and executes the resulting string. The bug is that this includes executing anything after the function definition as well.

所描述的修复显然是为了解析结果以查看它是否是有效的函数定义.如果不是，则打印有关无效函数定义尝试的警告.

The fix described is apparently to parse the result to see if it's a valid function definition. If not, it prints the warning about the invalid function definition attempt.

这篇文章证实了我对错误原因的解释.它还详细介绍了修复程序如何解决它:它们不仅更仔细地解析值，而且用于传递导出函数的变量遵循特殊的命名约定.这种命名约定与为 CGI 脚本创建的环境变量所使用的命名约定不同，因此 HTTP 客户端应该永远无法踏入这扇门.

This article confirms my explanation of the cause of the bug. It also goes into a little more detail about how the fix resolves it: not only do they parse the values more carefully, but variables that are used to pass exported functions follow a special naming convention. This naming convention is different from that used for the environment variables created for CGI scripts, so an HTTP client should never be able to get its foot into this door.

这篇关于Bash 中的 Shellshock 漏洞背后的行为是记录在案还是有意为之?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！