arithmetic expression from outside

arithmetic expression from outside

[YAMAGUCHI Takanori]

Is this an intended behaviour?

% cat sum.sh
sum=0
while read n; do
  sum=$((sum+n))
done
echo $sum
% seq 10 | zsh sum.sh
55
% yes ++sum | head -10 | zsh sum.sh
2046
% echo 'sum[$(echo Hello, world!>&2)]' | zsh sum.sh
Hello, world!
sum.sh:3: bad math expression: empty string
% zsh -c 'echo $ZSH_VERSION'
5.5.1

Re: arithmetic expression from outside

[Bart Schaefer]

On Thu, Sep 5, 2019 at 1:50 AM YAMAGUCHI Takanori <t-yama@iij.ad.jp> wrote:
>
> Is this an intended behaviour?

It's the way evaluation of variables in math expressions is defined,
yes.  Similarly in ksh:

% echo 'sum[$(echo Hello, world!>&2)]' | ksh -c 'read n; echo $((n))
Hello, world!
ksh: sum: parameter not set

Also environment variables:

% N='sum[$(echo Hello, world!>&2)]' ksh -c 'echo $((N))'
Hello, world!
ksh: sum: parameter not set

(I have a 2012 ksh so maybe this is different now.)

Bash 3.2.57 does the same, although without complaining about the
unset parameter:

% N='sum[$(echo Hello, world!>&2)]' bash -c 'echo $((N))'
Hello, world!
0

Zsh at least does not do that with parameters from the environment,
although I'm not exactly sure what prevents it.

Re: arithmetic expression from outside

[Stephane Chazelas]

2019-09-05 11:22:53 -0700, Bart Schaefer:
[...]
> % N='sum[$(echo Hello, world!>&2)]' bash -c 'echo $((N))'
> Hello, world!
> 0
> 
> Zsh at least does not do that with parameters from the environment,
> although I'm not exactly sure what prevents it.

It does, but the variable has to be an array:

$ N='psvar[$(echo Hello, world!>&2)]' zsh -c 'echo $((N))'
Hello, world!
zsh:1: bad math expression: empty string

See also
https://unix.stackexchange.com/questions/172103/security-implications-of-using-unsanitized-data-in-shell-arithmetic-evaluation

That's regularly reported as a security vulnerability or at
least a misfeature that causes security vulnerabilities (to bash
and zsh at least; first time I heard about it was from Oliver
Kiddle here shortly after shellshock) and I agree it is.

It would be nice if something could be done about it, but I'm
not sure there's an easy solution other than redesigning a new
arithmetic expression parsing from scratch.

POSIX gets in the way because it requires $(($1)) to be done in
two steps: first expansion of $1 and then evaluation of the
expression resulting from that expansion (so with a value like
PATH=7734, you get a nasty side effect even with dash or other
shells that don't have extensions over the standard).

I'm not sure we can do anything safe without coming up with a
completely new, incompatible and pretty limited syntax.

-- 
Stephane

Re: arithmetic expression from outside

[YAMAGUCHI Takanori]

This behaviour looks to be unsafe.
I wish it had a feature to disable the recursive evaluation
of an arithmetic expression. Or at least zshmisc manpage
should be added the warning not to use unchecked input
in an arithmetic expression context.

Re: arithmetic expression from outside

[Daniel Shahaf]

Bart Schaefer wrote on Thu, Sep 05, 2019 at 11:22:53 -0700:
> On Thu, Sep 5, 2019 at 1:50 AM YAMAGUCHI Takanori <t-yama@iij.ad.jp> wrote:
> >
> > Is this an intended behaviour?
> 
> It's the way evaluation of variables in math expressions is defined,
> yes.

What's the recommended alternative, then?