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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
