'set' leaks garbage from environment

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]