Re: Zsh - Multiple DoS Vulnerabilities

[David Wells <bughunters@xxxxxxxxxxx>]

Thanks for taking a look at these bugs. As Stephanie mentioned, security
related risk may depend more on Zsh usage, and being that these crashes are
Invalid Memory Access issues, they might allow an attacker to disclose
parts of memory to help with a pre-exploitation process. It looks like
there is patch activity on this thread, would you be able to provide me
update on expected patch date and issues you are patching? Thank you.

On Sun, May 12, 2019 at 9:21 AM Stephane Chazelas <
stephane.chazelas@xxxxxxxxx> wrote:

> 2019-05-10 09:37:15 -0700, Bart Schaefer:
> > It would be helpful if you could explain how this would be exploited
> > by someone who is not already able to cause the zsh user to execute
> > some other arbitrary commands.  What's the point of crashing
> > somebody's shell if you can instead make it remove all their files or
> > email you their private ssh keys or something?
>
> I'd second that.
>
> I suspect it's shellshock aftermath.
>
> Before shellshock, the bash parser was invoked on the content of any
> environment variable that started with (), so on attacker
> supplied data as opposed to code of script authors.
>
> bash initially didn't check that the content of the variable was
> limited to only a function body. After that bug was fixed, the
> bash parser was still exposed to arbitrary env vars, and so
> people started "fuzzing" the bash parser to discover
> vulnerabilities that could be exploited. Quickly, bash was fixed
> so that it was not exposed to arbitrary variables, so most of
> those vulnerabilities in the parser became minor bugs.
>
> A few of those were still found long after shellshock was fixed
> though.
>
> I can't see David's reports, but they do sound like similar
> fuzzing test reports.
>
> After shellshock a few related vulnerabilities were found in
> zsh, where for instance the zsh arithmetic expression parser
> (and by extension the full parser) was invoked on the content of
> *some* specific env vars (like SHLVL). That's Oliver's (IIRC)
>
> $ SHLVL='psvar[0$(uname>&2)]' zsh -c ''
> Linux
>
> But those were fixed. Nowadays, I don't think zsh's parser is
> invoked on attacker supplied-data, and if it were, the fact that
> the code crashes the shell would be, as you say, the least of
> our worries.
>
> There is one exception I can think of though: the restricted
> mode.
>
> That's one mode where the attacker can be the shell code author.
>
> If those bugs allow the user to escape the restricted shell
> jail, then it would be a concern. If however the only problem is
> the crashing of the shell, then it would not be a concern, as
> the user can always do "kill -s SEGV $$" to crash the shell (or
> set and reach some limits, or do a deep recursion...).
>
> Now, I don't think we need those bugs to escape a restricted
> shell jails as those are almost impossible to implement
> reliably and are an anachronism nowadays IMO.
>
> I would be of the opinion that that feature should be removed
> (I'd be curious to know if anybody has ever used it).
>
> At least, we should give more warning about it and recommend
> alternatives. Here's an attempt below:
>
> diff --git a/Doc/Zsh/restricted.yo b/Doc/Zsh/restricted.yo
> index 6cf9b36b5..121e2ae8d 100644
> --- a/Doc/Zsh/restricted.yo
> +++ b/Doc/Zsh/restricted.yo
> @@ -37,3 +37,46 @@ Restricted mode can also be activated any time by
> setting the
>  tt(RESTRICTED) option.  This immediately enables all the restrictions
>  described above even if the shell still has not processed all startup
>  files.
> +
> +A shell em(Restricted Mode) is an ancient way to restrict what users may
> +do. However modern systems have better, safer and more reliable ways to
> +confine user actions like em(chroot jails), em(containers) or em(zones).
> +
> +A restricted shell is very difficult to implement safely. That feature
> +may be removed in a future version of zsh.
> +
> +It's important to realise the restrictions only apply to the shell and
> +not to the commands it runs (except for some of its builtins). While a
> +restricted shell can only run the restricted list of commands accessible
> +via the predefined `tt(PATH)` variable, it doesn't prevent those
> +commands from running any other command.
> +
> +As an example, if `tt(env)' is among the list of em(allowed) commands,
> +then it allows the user to run any command as `tt(env)` is not a shell
> +builtin command and can run arbitrary executables.
> +
> +So when implementing a restricted shell framework it's important to be
> +fully aware of what actions each of the em(allowed) commands or features
> +(think em(modules)) can perform.
> +
> +Many commands can have their behaviour affected by environment
> +variables. Except for the few listed above, zsh doesn't restrict setting
> +environment variables.
> +
> +Having a `tt(perl)', `tt(python)', `tt(bash)` script as a restricted
> +command probably means the user can work around the restriction by
> +setting specially crafted `tt(PERL5LIB)', `tt(PYTHONPATH)',
> +`tt(BASHENV)' environment variables. On GNU systems, one can have any
> +command doing character set conversion (which includes zsh itself) run
> +arbitrary code by setting a `tt(GCONV_PATH)' environment variable, those
> +are only a few examples.
> +
> +Bear in mind that contrary to some other shells, `tt(readonly)' is not a
> +security feature in zsh as it can be undone and so cannot be used to
> +mitigate the above.
> +
> +A restricted shell is only going to work if the allowed commands are few
> +and carefully written so as not to grant more access to users than
> +intended. It's also important to restrict what zsh module the user may
> +load as some of them like `tt(zsh/system)', `tt(zsh/mapfile)' or
> +`tt(zsh/files)' would allow bypassing most of the restrictions.
>
> --
> Stephane
>
>