Do not evaluate arithmetic expressions from environment variables at startup, validation

[hyenias]

I was reading over the wiki and tried the following referenced check for CVE-2019-14868 as it relates to command execution via startup environment variables. To my surprise, it seemed to work when my shell was ksh93 but not when my shell was bash or zsh. Is this because my current ksh parent process is evaluating the contents of SHLVL before passing it along to the new ksh invocation?

$ echo $KSH_VERSION
Version AJMv 93u+m/1.0.0-alpha+37c9ac27 2021-03-01
$ SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]' ksh
DANGER WILL ROBINSON
$

[McDutchie]

The CVE vulnerability you're referencing should have been fixed in 593a5a8.

Is this because my current ksh parent process is evaluating the contents of SHLVL before passing it along to the new ksh invocation?

I believe so, though arguably it should not be doing that because of the single quotes. But it's easy to test:

$ export SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]'
DANGER WILL ROBINSON

That happens in the current shell, no other shell is even launched.

What actually gets passed to the child shell is the value '3'. This can be tested as follows:

$ SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]' env | grep ^SHLVL=
DANGER WILL ROBINSON
SHLVL=3

[McDutchie]

I think this is caused by the fact that SHLVL is pre-declared as an integer variable, so any assignment will automatically be evaluated as an arithmetic expression

And in arithmetic expressions, command substitutions in array indices are evaluated as well, even if they were passed as literal and quoted strings. I think that is pretty bogus. It might warrant an issue of its own.

[hyenias]

Thank you for triple checking this. I do appreciate it.

I believe #152 covers this then.

[McDutchie]

Another check, to be extra sure:

$ env SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]' ksh
$

Nothing untoward happens if we stop the current shell from evaluating the expression.