* zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash @ 2014-09-24 14:45 İsmail Dönmez 2014-09-24 14:54 ` Frank Terbeck ` (3 more replies) 0 siblings, 4 replies; 15+ messages in thread From: İsmail Dönmez @ 2014-09-24 14:45 UTC (permalink / raw) To: Zsh Hackers' List [-- 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-24 14:45 zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash İsmail Dönmez @ 2014-09-24 14:54 ` Frank Terbeck 2014-09-24 14:55 ` İsmail Dönmez 2014-09-24 15:01 ` Peter Stephenson 2014-09-24 14:55 ` Jérémie Roquet ` (2 subsequent siblings) 3 siblings, 2 replies; 15+ messages in thread From: Frank Terbeck @ 2014-09-24 14:54 UTC (permalink / raw) To: İsmail Dönmez; +Cc: Zsh Hackers' List İ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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-24 14:54 ` Frank Terbeck @ 2014-09-24 14:55 ` İsmail Dönmez 2014-09-24 15:01 ` Peter Stephenson 1 sibling, 0 replies; 15+ messages in thread From: İsmail Dönmez @ 2014-09-24 14:55 UTC (permalink / raw) To: Frank Terbeck; +Cc: Zsh Hackers' List [-- 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 :) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-24 14:54 ` Frank Terbeck 2014-09-24 14:55 ` İsmail Dönmez @ 2014-09-24 15:01 ` Peter Stephenson 2014-09-24 15:08 ` Frank Terbeck 2014-09-24 15:13 ` Jérémie Roquet 1 sibling, 2 replies; 15+ messages in thread From: Peter Stephenson @ 2014-09-24 15:01 UTC (permalink / raw) To: Frank Terbeck, Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-24 15:01 ` Peter Stephenson @ 2014-09-24 15:08 ` Frank Terbeck 2014-09-24 15:13 ` Jérémie Roquet 1 sibling, 0 replies; 15+ messages in thread From: Frank Terbeck @ 2014-09-24 15:08 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-24 15:01 ` Peter Stephenson 2014-09-24 15:08 ` Frank Terbeck @ 2014-09-24 15:13 ` Jérémie Roquet 1 sibling, 0 replies; 15+ messages in thread From: Jérémie Roquet @ 2014-09-24 15:13 UTC (permalink / raw) To: Peter Stephenson; +Cc: Frank Terbeck, Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-24 14:45 zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash İsmail Dönmez 2014-09-24 14:54 ` Frank Terbeck @ 2014-09-24 14:55 ` Jérémie Roquet 2014-09-24 14:59 ` Chet Ramey 2014-09-25 13:11 ` Peter Stephenson 3 siblings, 0 replies; 15+ messages in thread From: Jérémie Roquet @ 2014-09-24 14:55 UTC (permalink / raw) To: İsmail Dönmez; +Cc: Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-24 14:45 zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash İsmail Dönmez 2014-09-24 14:54 ` Frank Terbeck 2014-09-24 14:55 ` Jérémie Roquet @ 2014-09-24 14:59 ` Chet Ramey 2014-09-25 13:11 ` Peter Stephenson 3 siblings, 0 replies; 15+ messages in thread From: Chet Ramey @ 2014-09-24 14:59 UTC (permalink / raw) To: İsmail Dönmez, Zsh Hackers' List; +Cc: 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/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-24 14:45 zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash İsmail Dönmez ` (2 preceding siblings ...) 2014-09-24 14:59 ` Chet Ramey @ 2014-09-25 13:11 ` Peter Stephenson 2014-09-26 14:03 ` Oliver Kiddle 3 siblings, 1 reply; 15+ messages in thread From: Peter Stephenson @ 2014-09-25 13:11 UTC (permalink / raw) To: Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-25 13:11 ` Peter Stephenson @ 2014-09-26 14:03 ` Oliver Kiddle 2014-09-26 20:08 ` Peter Stephenson 0 siblings, 1 reply; 15+ messages in thread From: Oliver Kiddle @ 2014-09-26 14:03 UTC (permalink / raw) To: Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash 2014-09-26 14:03 ` Oliver Kiddle @ 2014-09-26 20:08 ` Peter Stephenson 2014-09-29 10:04 ` PATCH: safe numeric import Peter Stephenson 0 siblings, 1 reply; 15+ messages in thread From: Peter Stephenson @ 2014-09-26 20:08 UTC (permalink / raw) To: Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* PATCH: safe numeric import 2014-09-26 20:08 ` Peter Stephenson @ 2014-09-29 10:04 ` Peter Stephenson 2014-09-29 15:24 ` Bart Schaefer ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Peter Stephenson @ 2014-09-29 10:04 UTC (permalink / raw) To: Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PATCH: safe numeric import 2014-09-29 10:04 ` PATCH: safe numeric import Peter Stephenson @ 2014-09-29 15:24 ` Bart Schaefer 2014-10-01 14:57 ` [Bulk] " Oliver Kiddle 2014-10-02 16:06 ` Peter Stephenson 2 siblings, 0 replies; 15+ messages in thread From: Bart Schaefer @ 2014-09-29 15:24 UTC (permalink / raw) To: Zsh Hackers' List 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bulk] PATCH: safe numeric import 2014-09-29 10:04 ` PATCH: safe numeric import Peter Stephenson 2014-09-29 15:24 ` Bart Schaefer @ 2014-10-01 14:57 ` Oliver Kiddle 2014-10-02 16:06 ` Peter Stephenson 2 siblings, 0 replies; 15+ messages in thread From: Oliver Kiddle @ 2014-10-01 14:57 UTC (permalink / raw) To: Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PATCH: safe numeric import 2014-09-29 10:04 ` PATCH: safe numeric import Peter Stephenson 2014-09-29 15:24 ` Bart Schaefer 2014-10-01 14:57 ` [Bulk] " Oliver Kiddle @ 2014-10-02 16:06 ` Peter Stephenson 2 siblings, 0 replies; 15+ messages in thread From: Peter Stephenson @ 2014-10-02 16:06 UTC (permalink / raw) To: Zsh Hackers' List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-10-02 16:06 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-24 14:45 zsh seems to be vulnerable to CVE-2014-6271: remote code execution through bash İsmail Dönmez 2014-09-24 14:54 ` Frank Terbeck 2014-09-24 14:55 ` İsmail Dönmez 2014-09-24 15:01 ` Peter Stephenson 2014-09-24 15:08 ` Frank Terbeck 2014-09-24 15:13 ` Jérémie Roquet 2014-09-24 14:55 ` Jérémie Roquet 2014-09-24 14:59 ` Chet Ramey 2014-09-25 13:11 ` Peter Stephenson 2014-09-26 14:03 ` Oliver Kiddle 2014-09-26 20:08 ` Peter Stephenson 2014-09-29 10:04 ` PATCH: safe numeric import Peter Stephenson 2014-09-29 15:24 ` Bart Schaefer 2014-10-01 14:57 ` [Bulk] " Oliver Kiddle 2014-10-02 16:06 ` Peter Stephenson
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).