From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-33254-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 14117 invoked by alias); 26 Sep 2014 20:14:06 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 33254
Received: (qmail 13083 invoked from network); 26 Sep 2014 20:13:53 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.2
X-Originating-IP: [80.3.229.105]
X-Spam: 0
X-Authority: v=2.1 cv=Ku/D2AmN c=1 sm=1 tr=0 a=uz1KDxDNIq33yePw376BBA==:117
 a=uz1KDxDNIq33yePw376BBA==:17 a=NLZqzBF-AAAA:8 a=uObrxnre4hsA:10
 a=kj9zAlcOel0A:10 a=BrDiTsk0AAAA:8 a=d2slK8E0X_3DymQGND0A:9 a=CjuIK1q_8ugA:10
 a=-hJg1tCh9CgA:10
Date: Fri, 26 Sep 2014 21:08:18 +0100
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: "Zsh Hackers' List" <zsh-workers@zsh.org>
Subject: Re: zsh seems to be vulnerable to CVE-2014-6271: remote code
 execution through bash
Message-ID: <20140926210818.3ac1bf20@pws-pc.ntlworld.com>
In-Reply-To: <22772.1411740194@thecus.kiddle.eu>
References: <CAJ1KOAjyBjbywavXwa+ejjQD1YjK8eCSGaESYhJxCb1e3KPjFg@mail.gmail.com>
	<20140925141133.49a7127b@pwslap01u.europe.root.pri>
	<22772.1411740194@thecus.kiddle.eu>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 26 Sep 2014 16:03:14 +0200
Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> For specials of numeric type we appear to be doing math evaluation on
> their values.
>   OPTIND='3+4' zsh -c 'echo $OPTIND'
> And if you think you can't do anything with math evaluation:
>   x='`date >&2`' OPTIND='pipestatus[1${(e)x}]' zsh -c ':'
> 
> Other shells don't even import OPTIND.

This affects OPTIND, TRY_BLOCK_ERROR and SHLVL.  It makes no sense
to import the first two at all; they reflect internal status and having
them initialised to something from outside seems wrong.

SHLVL does need to be imported, but doesn't need to be evaluated on
import --- if it's not a straight integer at this point something is
screwy.  So this could be checked.

> Would it perhaps make sense to
> revert the sense of PM_DONTIMPORT and have a PM_IMPORT flag so any new
> special is not imported unless whoever implements it actually gives it
> some thought.

Yes, probably.

pws