2014-09-30 09:04:28 -0600, Eric Blake: > On 09/30/2014 08:42 AM, Eric Blake wrote: > > Thanks; here's another ksh bug: > > > > $ env 'a|b=' bash -c 'set | grep a"."b' > > $ env 'a|b=' ksh -c 'set | grep a"."b' > > a|b='' > > > > But per the documentation of set, "If no options or arguments are > > specified, set shall write the names and values of all shell variables > > in the collation sequence of the current locale." > > Or, reading further, "The output shall be suitable for reinput to the > shell, setting or resetting, as far as possible, the variables that are > currently set;" > > but with the current output of set, trying to invoke 'eval "$(set)"' > will end up executing the command 'a' in the current working directory > rather than setting the "variable" "a|b". While the bash Shell Shock > bug has already established that arbitrary environment variable names > are a far less likely attack vector than arbitrary environment variable > values, I still can't help but wonder if someone can come up with an > exploit where a ksh script that runs with elevated privileges and tries > to eval the output of set will end up running code of the caller's choice. [...]
Same with "export -p": $ env -i $'a\necho test\na=b' ksh -c 'export -p' | ksh test And bash is also vulnerable. $ env -i $'a\necho test\na=b' bash -c 'export -p' declare -x OLDPWD declare -x PWD="/home/stephane" declare -x SHLVL="1" declare -x a echo test a (that output doesn't make much sense, suggesting it may also hide more bugs and vulnerabilities). -- Stephane
