The recent changes in bash have prompted me to look closer at dash's behavior with unusual name/value settings in the environment. I found at least two bugs: Per the documentation of set, http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#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.... The output shall be suitable for reinput to the shell, setting or resetting, as far as possible, the variables that are currently set;" Elsewhere, http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html "Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names." Here's the behavior I observe with dash 0.5.7 (as built for Fedora 20): $ env 'a|b=' dash -c 'set | grep a"."b' a|b='' Oops - set is claiming that 'a|b' is the name of a current shell variable; but this is impossible. Worse, the text quoted from POSIX means that I should be able to safely do: $ dash -c 'eval "$(set)"' but if "a|b=' is in the environment, this will try to invoke the command named 'a', rather than set a variable named a|b. This is NOT as severe as the bash Shell Shock bug (Shell Shock only required control over values, while this requires control over arbitrary names in the environment), but I still wonder if someone might be able to exploit this into causing some dash script into executing code of the caller's choice under the elevated permissions that the script is running under. Dash should follow the lead of bash, and refuse to list any inherited environment variable that is not a valid variable name. However, it's probably up to you to either remove those non-names from the environment entirely, or to act like bash and merely hang on to those name-value pairs to hand on to the child process even though it is untouchable from within dash. Next bug: $ dash -c 'unset "a|b" $ echo $? 0 This should fail (as in bash and ksh), rather than silently succeeding, since it is not possible to unset a non-valid name. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
