zsh-workers
 help / color / mirror / code / Atom feed
From: David Wells <bughunters@tenable.com>
To: David Wells <bughunters@tenable.com>,
	Bart Schaefer <schaefer@brasslantern.com>,
	 "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: Zsh - Multiple DoS Vulnerabilities
Date: Mon, 13 May 2019 09:29:36 -0700	[thread overview]
Message-ID: <CAAOKOsfq-BDfbD1MD01f-soJdhK=rbvr-1kHubCs9uT4GNhG0g@mail.gmail.com> (raw)
In-Reply-To: <20190512162149.3fsqupqftmwxrbvd@chaz.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5947 bytes --]

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@gmail.com> 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
>
>

  reply	other threads:[~2019-05-13 16:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 15:03 David Wells
2019-05-10 16:37 ` Bart Schaefer
2019-05-12 16:21   ` Stephane Chazelas
2019-05-13 16:29     ` David Wells [this message]
2019-05-13 22:02       ` Bart Schaefer
2019-05-14 18:10       ` Stephane Chazelas
2019-05-14 21:24         ` Daniel Shahaf
2019-05-14 21:38           ` Bart Schaefer
2019-05-14 21:39         ` Daniel Shahaf
2019-05-14 22:25           ` Bart Schaefer
2019-05-15 10:48             ` Daniel Shahaf
2019-05-31 12:05     ` [PATCH] [doc] [repost] warnings about restricted shell (Was: Zsh - Multiple DoS Vulnerabilities) Stephane Chazelas
2019-06-03  9:35       ` Peter Stephenson
2019-06-04  2:39       ` dana
2019-06-04  7:34         ` dana
2019-05-10 20:27 ` Zsh - Multiple DoS Vulnerabilities Bart Schaefer
2019-05-11  1:45   ` #7 (typeset -Tp) (was Re: Zsh - Multiple DoS Vulnerabilities) Oliver Kiddle
2019-05-13  9:01     ` Peter Stephenson
2019-05-13 21:11   ` PATCH: #6 negative job id (Re: " Oliver Kiddle
2019-05-13 21:44   ` Zsh - Multiple DoS Vulnerabilities Oliver Kiddle
2019-05-13 22:36   ` #3 typeset and braces (Re: Zsh - Multiple DoS Vulnerabilities) Oliver Kiddle
2019-05-14  0:13     ` Mikael Magnusson
2019-05-14  5:38       ` Bart Schaefer
2019-05-14 10:50     ` Peter Stephenson
2019-05-14 16:38   ` Zsh - Multiple DoS Vulnerabilities Peter Stephenson
2019-05-14 20:30   ` Oliver Kiddle
2019-05-15 16:50     ` Mikael Magnusson
2019-05-16 20:37     ` Peter Stephenson
2019-05-17 13:41       ` Mikael Magnusson
2019-05-17 13:51         ` Mikael Magnusson
2019-05-17 14:28           ` Mikael Magnusson
2019-05-18 10:31           ` Oliver Kiddle
2019-05-21 14:43             ` Oliver Kiddle
     [not found]               ` <CGME20190521154256eucas1p1f0816d2467abd8bf4a0c31058af2983a@eucas1p1.samsung.com>
2019-05-21 15:42                 ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAOKOsfq-BDfbD1MD01f-soJdhK=rbvr-1kHubCs9uT4GNhG0g@mail.gmail.com' \
    --to=bughunters@tenable.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).