From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id d9dfcd1e for ; Mon, 13 May 2019 16:30:51 +0000 (UTC) Received: (qmail 10791 invoked by alias); 13 May 2019 16:30:34 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44289 Received: (qmail 29641 invoked by uid 1010); 13 May 2019 16:30:34 -0000 X-Qmail-Scanner-Diagnostics: from us-smtp-delivery-195.mimecast.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25447. spamassassin: 3.4.2. Clear:RC:0(63.128.21.195):SA:0(-2.7/5.0):. Processed in 3.315273 secs); 13 May 2019 16:30:34 -0000 X-Envelope-From: dwells@tenable.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at us._netblocks.mimecast.com designates 63.128.21.195 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenable.com; s=mimecast20170201; t=1557764992; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:openpgp:autocrypt; bh=1ex73jP2Ol9xdZWTl7AmJFxf7JkkfO3WQN9aNtIKRS0=; b=E+9xjSkH9gyLr78SUL6ntyjdpGySJXbegiTqvi4G70bQzSoIGLr0wktXIgvjlH/OxUd8Cz k1zR1S/OKXPllyIE4BkEQVpE2X/cbFgk3qO4lzz410qNymN6VBkNF8JxvCsQeVPg2gkgg1 5EQXsni+Kfef5WobH2vjBZUBPFcavIk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=3fDVyZg4zTQo6PAcSstyW2f7cv5I1ljUhnuURaI4uWU=; b=Ei+EsATZTgQzcq7/H31DnjcT7Mw9uGPw9LgMxAEZCteTmTzDcfNQ4yxcvoGuwAp8Pz fUl/RuLrLF1otIO6LMVH5RzorKMNHYS6DfGmNwE6ts2hqBgRN2YEKffklMdCfsVIwf98 FYZZtrS1t3Zv4WWXc7ahaqnKCDmIKY1BXE0ahSMGAWpzW46j0b1DVdkBJefoU3WYDOIH OhZu0Xb6efpNAxmvmtcv0N2r0DFhF95dtBLt8t08FZOZrshffp/PqPr3h/w8zELa5htW Cj2qKp0hugyk2JAo9Z0qCuVfv+5xBfgEvJCUFBgc9rvvmz+pP6tXyCTyUggUcMJ/zxDY mK7Q== X-Gm-Message-State: APjAAAWcSvF+MSIpc6W9p9Hyl99SlpdzvxTrmsEIKWcZ4f3PXnvshQqm 7suCVMG5jQCpfc/P9DRYTsVwaYAE3h8GuK2DDf2nRwcvZAWiVJILhJGd9BwgLKcnuRJ6pYNoEHN MnszmsyOu5npK50CQE0YLl6oE1v7s X-Received: by 2002:a65:62cc:: with SMTP id m12mr32200705pgv.118.1557764989078; Mon, 13 May 2019 09:29:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqyt7g5dHM+gSgxYW7iOtTjKf5+jlh8KYAhk1z2IAuGBqXfIeX2XpI0N+4Yc1BlK1r+8Mg/JwE+1+QdDxiSFPfc= X-Received: by 2002:a65:62cc:: with SMTP id m12mr32200644pgv.118.1557764988495; Mon, 13 May 2019 09:29:48 -0700 (PDT) MIME-Version: 1.0 References: <20190512162149.3fsqupqftmwxrbvd@chaz.gmail.com> In-Reply-To: <20190512162149.3fsqupqftmwxrbvd@chaz.gmail.com> From: David Wells Date: Mon, 13 May 2019 09:29:36 -0700 Message-ID: Subject: Re: Zsh - Multiple DoS Vulnerabilities To: David Wells , Bart Schaefer , "zsh-workers@zsh.org" X-MC-Unique: WZxaSUkJNXyzko5J46JorA-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="000000000000c889600588c76cc8" --000000000000c889600588c76cc8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3D'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 > > --000000000000c889600588c76cc8--