Re: Zsh - Multiple DoS Vulnerabilities

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

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