2014-10-10 09:04:10 -0600, Eric Blake: > On 10/10/2014 08:55 AM, Stephane Chazelas wrote: > > > But I can't see why the content of a variable should be > > interpreted as anything else than an arithmetic expression just > > because it's in an array subscript. > > For the record, there are vulnerable shell scripts in the wild that fail > to sanitize their inputs before passing it through arithmetic expansion, > all because MULTIPLE shells (bash, ksh, mksh, zsh) all have the same > semantic decision of performing command substitution as part of > arithmetic expansion. For example: > > $ /usr/sbin/fsadm -n resize /dev/sdb '0+x[`id >/dev/tty`]T' > > demonstrates that fsadm is vulnerable for trying to do $(($1)) without > sanitizing $1 first. [...]
In this case though, it would still be vulnerable with a strictly POSIX shell as with /usr/sbin/fsadm -n resize /dev/sdb 'PATH=1' The evaluation of $(($1)) when $1 is 'PATH=1' is required to assign 1 to PATH. What is unspecified by POSIX is: var=PATH=1; : $((var)) so changing the shell so it no longer does assignments and other expansions upon indirect/nested/recursive arithmetic evaluation would not break POSIX compliance (so could be done by ksh/bash/zsh when invoked as sh), but you'd still have a problem if you did: var=PATH=1; : $(($var)) But at least in that case, it's more obvious that you need to sanitize the input. -- Stephane
