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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 f2df60e5 for ; Sun, 12 May 2019 16:22:45 +0000 (UTC) Received: (qmail 22367 invoked by alias); 12 May 2019 16:22:29 -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: 44286 Received: (qmail 15561 invoked by uid 1010); 12 May 2019 16:22:29 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr1-f49.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25440. spamassassin: 3.4.2. Clear:RC:0(209.85.221.49):SA:0(-2.0/5.0):. Processed in 1.715374 secs); 12 May 2019 16:22:29 -0000 X-Envelope-From: stephane.chazelas@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.221.49 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=FS4x5LsUW88GsVN2RtcF+1B9YlMLJj6X5WZo+SY/Swo=; b=Nr3KQHd573Zko5OZ0QbOwFJTLfMv7DuZu5ijyyjLaZsOPOfS2rZiJo7tRDSUG73Wjy AbwILlWzRelLznLAcYUnkPqXH2qMhdHyiKUJ1YhgjSN8IhhJAIDHDEChw8TCSHQBrkzI 0SdsIiO8qNF9/YEuMN+mZDFTRPJms4YJAbodX/PMIQQrE8uaL0F7/EasuxkqP3IW7Y8N HzsSxGuVMQ0vhnuMafnF+ZiP4Q+htnacZzsIoPtti+D8bkj8G1xO+CSLgBHYBgXX8yw2 TdPxv3WNGYT53adAX7nUqXa/6G3fWBFyJQeojftT/Bw9SjgBgWJ9pJB4a/EZ57pGeDSp +eLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=FS4x5LsUW88GsVN2RtcF+1B9YlMLJj6X5WZo+SY/Swo=; b=EWPat2ZJzxoVSjT+Uj/DmWbYLWMus8ew+qrx2y/kat4a9t/zoOIb0fa6JPhCCSv7cQ 17NjuTtnWkfjfHyR85YCG1Fc4Fiug8ssYn7wmvs+qP/ZknYONNsdRx7bMcZXCnNtcOig kLuGVwpnlNK6kC9pjwED2fXNdNnPfg9MWm04SO8qHpyFm2Vm+PlU6TzDgvj1aV2+l4T8 V+cGqfnM3ZeQEPzkRChQVJihq7VZrl7I61V96RPvmNiaVAbE3hdeZAnPxn56IxiXNlk5 +suqeWS5qV/6KSfXmnjo6Edz9Vyd+rColhLGeslzk5ZIp59sW3T7y4BsDh28n5Fw61lE qzPQ== X-Gm-Message-State: APjAAAXvLkRS+Wk2u1xPPHp2hhcp7v+/r7RnbfJMhiEHvqcNFZzFnkfU QV4Z/WWSGQnuYle/az340hY= X-Google-Smtp-Source: APXvYqz13Hh2WMQg0HxMyEmr3gba9DxgWoRbLQ0QRpuc2zGvMEQqEP/cmfTNyCSkOues3XTPBIM3Pg== X-Received: by 2002:a5d:6812:: with SMTP id w18mr4559457wru.16.1557678112038; Sun, 12 May 2019 09:21:52 -0700 (PDT) Date: Sun, 12 May 2019 17:21:49 +0100 From: Stephane Chazelas To: Bart Schaefer Cc: David Wells , "zsh-workers@zsh.org" Subject: Re: Zsh - Multiple DoS Vulnerabilities Message-ID: <20190512162149.3fsqupqftmwxrbvd@chaz.gmail.com> Mail-Followup-To: Bart Schaefer , David Wells , "zsh-workers@zsh.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 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