我了解CVE-2014-6271的原始testing,即:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
但是我对CVE-2014-7169的更新testing和相应输出感到困惑:
$ env X='() { (a)=>\' sh -c "echo date"; cat echo sh: X: line 1: syntax error near unexpected token `=' sh: X: line 1: `' sh: error importing function definition for `X' Thu 25 Sep 2014 08:50:18 BST
有人可以简要地解释这里发生了什么,以及如何绕过CVE-2014-6271的补丁?
自从我第一次发布这个问题以来,我一直在网上search。
根据bug的原始发现者 ,在CVE-2014-6271补丁之前的bash导入了一个函数,例如:
foo=() { code }
通过用空格replace等号并解释它,这意味着超出函数定义的解释是可能的。
CVE-2014-6271的修补程序 引入了parse_and_execute()函数的特殊模式,以将评估限制在函数定义中,而不是超出它。
但是,正如此线程中所述,CVE-2014-7169漏洞testing的特制环境variablesdevise为:1)将分析器混淆为死亡2)在缓冲区中留下碎片3)彻底更改原始bash命令的作用它与已经在缓冲区中的碎片相结合。
所以要parsing这个环境variables:
X='() { (a)=>\'
() { (a)=>\
。 请注意\
是string的一部分; 它不是逃避尾随的单引号。 () {
(a)=
>\
>\[NEWLINE]
sh
命令运行之前的某一时刻,一个换行符被放置在缓冲区中。 >\[NEWLINE]echo date
sh
被调用(在这种情况下可能是bash的符号链接)时,它会将其命令参数echo date
添加到已存在于缓冲区中的字符。 >echo date
>echo date
,这与date > echo
具有相同的效果。 创build一个名为echo
的文件,并将date
命令的stdoutredirect到它。 ; cat echo
它不给你一个很好的清洁输出,但它确实显示了错误。
没有错误,环境variablesX
应该被忽略,bash应该运行echo date
,并且cat应该抱怨没有叫做echo的文件。 例如考虑短跑的行为:
me@myserver$ rm -f echo && env -i X='() { (a)=>\' dash -c 'echo date'; cat echo date cat: echo: No such file or directory
我不会重复你在问题中显示的输出,我不会假装理解它是如何工作的,但是bash运行date
并把输出放到一个名为“echo”的文件中。 你可以玩替代date
以说服自己,这是可用和危险的。