I asked a related question on defining and using shell functions in bash. In this question I want to ask specifically which way of defining function can lead to shellshock. I did some tests and I want to confirm with everyone else. I am running bash v4.2 for the test.I understand to give a shell function definition to a subshell there are two ways:via shell variables + export into environmentvia shell function definition + export into environmentFor the first way:$ foo='() { echo hello world; }'$ export foo$ env | grep foofoo = () { echo hello world; }So for the second way:$ foo() { echo hello world; }$ export -f foo$ env | sed -n '/foo/{N;p}'foo = () { echo hello world}In both ways, the environment will have the shell function as a name-value pair [ foo = () { echo hello world; } ]. Now I am interested in CVE-2014-6271. I understand that this occurs due to how bash parses the trailing commands at end of function definition, but what I want to ask is whether both the above ways can lead to this ?For first case, I can define:$ foo='() { echo hello; }; echo world;'$ export foo$ env | grep foofoo = () { echo hello; }; echo world;$ bash -c fooworld // <-- shellshock bughelloHowever, for the second case, I'm not able to do the same:// won't put trailing echo in definition$ foo() { echo hello; }; echo world; // bad syntax$ foo() '{ echo hello; }; echo world;'So my question is although CVE-2014-6271 happens due to a parsing bug in the trailing commands after function definition in environment variable, can such a function definition ever be put in the environment via export -f <func> OR is the first case the only way for putting a trailing commands to cause shellshock ?
Bash shell functions and understanding shell shock
bash;shell