我问了相关的问题在 bash 中定义和使用 shell 函数。在这个问题中,我想具体问一下哪种定义函数的方式会导致 shellshock。我做了一些测试,想与其他人确认。我正在运行 bash v4.2 进行测试。
据我了解,为子 shell 提供 shell 函数定义有两种方法:
- 通过 shell 变量 + 导出到环境中
- 通过shell函数定义+导出到环境中
对于第一种方式:
$ foo='() { echo "hello world"; }'
$ export foo
$ env | grep foo
foo = () { echo "hello world"; }
那么对于第二种方式:
$ foo() { echo "hello world"; }
$ export -f foo
$ env | sed -n '/foo/{N;p}'
foo = () { echo "hello world"
}
在这两种方式中,环境都会将 shell 函数作为名称-值对[ foo = () { echo "hello world"; } ]
。现在我感兴趣的是CVE-2014-6271。我知道这是由于 bash 如何解析函数定义末尾的尾随命令而发生的,但我想问的是上述两种方式是否都会导致这种情况?
对于第一种情况,我可以定义:
$ foo='() { echo "hello"; }; echo "world";'
$ export foo
$ env | grep foo
foo = () { echo "hello"; }; echo "world";
$ bash -c foo
world // <-- shellshock bug
hello
但是,对于第二种情况,我无法执行相同的操作:
// won't put trailing echo in definition
$ foo() { echo "hello"; }; echo "world";
// bad syntax
$ foo() '{ echo "hello"; }; echo "world";'
所以我的问题是,尽管 CVE-2014-6271 的发生是由于环境变量中的函数定义后的尾随命令中的解析错误所致,但这样的函数定义是否可以通过export -f <func>
OR 放入环境中,这是第一种情况,这是放置尾随命令会导致 shellshock 吗?
答案1
问题:
...这样的函数定义是否可以通过 OR 放入环境中
export -f <func>
,第一种情况是放置尾随命令导致 shellshock 的唯一方法吗?
答:第一种情况是触发炮弹休克的唯一途径。
该漏洞是由对环境的解释触发的变量,不是导出函数的。
对恰好包含的环境变量的处理(){...}
被作为函数定义进行处理。和:对于尾随 的此类变量,将执行;cmd
该命令。cmd
核心问题是函数的解析并不限制函数的解释一可执行令牌,并将导出的 var 中包含的其余行作为可执行命令进行处理。
将执行限制为仅导出变量的一部分是第一次尝试修补。这显然是不够的,很快就发现几个额外的错误。
所以,不,该错误不是由于未能正确导出函数定义而导致的,并且;被读回(恰好完全由 shell 控制)。但结果是一些解析攻击者可能注入的变量值时出现问题。
无论如何,该错误的最初报告者是该网站的普通用户。他很可能是过来看看这个问题的。