Re: Follow-up to here-document bug reported on zsh-security

[Oliver Kiddle <opk@xxxxxxx>]

On 22 Aug, Bart Schaefer wrote:
> This is not:
>
> Src/zsh -fxc 'x()<<abcd;functions x'

For reference, the redirections on functions was added by Peter in 33285
/ cf6b0f56.

> Any here-document introducer of more than 3 characters produces this

The significance of more than 3 characters is that strings of up to 3
characters are included directly in the wordcode.

It is using execsimple() to run the command for defining the function so
eccopyredirs() doesn't get called.

For x()<<string, the wordcode parses as
LIST,SUBLIST,FUNCDEF,LIST,"x"ref,END,COND,END,END,LIST,SUBLIST,PIPE,REDIR,END,SIMPLE,END,END
Whereas for x(){}<<string it is quite different:
LIST,SUBLIST,PIPE,REDIR,END,SIMPLE,END,END,FUNCDEF,LIST,SUBLIST,END...

But there is apparently no problem with:

  eval 'x()<<string';functions x

With the following both strings are broken:

  zsh -fxc 'x() <<END1 { cat - } <<END2; functions x'

I'm fairly much stuck on trying to make sense of this.

One thing which particularly puzzles me about the wordcode stuff is why
ecnfunc is needed. Aren't the strings all effectively readonly. Why do
they need to be separate for each function. Certainly if you drop the
ecnfunc increments from the code, things break quite badly.

Bart: did you perhaps miss the second issue that was reported in
the same mail - the use after free in scanendscope() that probably
arrived in 53568 / abd541e18c.

Oliver

PS. Sorry about the accidental inclusion of the unicode characters from my
recent git push.