'set' leaks garbage from environment

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

Serves me right from testing on multiple machines :( I mixed up my test results.

Fedora 20 using dash 0.5.7 works:

$ dash -c 'unset "a|b"'
dash: 1: unset: a|b: bad variable name
$ rpm -q dash
dash-0.5.7-8.fc20.x86_64

But RHEL 6 fails:

$ dash -c 'unset "a|b"'
$ rpm -q dash
dash-0.5.5.1-4.el6.x86_64

so this is at least one bug that has already been fixed upstream.

Meanwhile, I just tested the latest dash.git (commit f21016a12) and this behavior is no longer present:

$ env 'a|b=' ./src/dash -c 'set | grep a"."b'

so it has also been fixed in the meantime. Sorry for not doing my homework; nothing to fix here...

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Works for me (tested on both Debian package versions 0.5.7-3 (wheezy) and 0.5.7-4 (unstable)):

$ dash -c 'unset "a|b"'
dash: 1: unset: a|b: bad variable name
$ echo $?
2

This I can reproduce though.

 --------------------------------------------------------------- 
| Olof Johansson                              http://stdlib.se/ |
|  irc: zibri                           https://github.com/olof |
 --------------------------------------------------------------- 

You were one of the people to reply to the first thread about that. :)

http://comments.gmane.org/gmane.comp.shells.dash/704

This is already fixed, and the fix has been released as part of 0.5.8.

Cheers,
Harald van Dijk