[Negitivefrags]

Can anyone confirm that this is still a security issue?

My reading of this is that it's weird, and it's certainly a bug in the parser, but because you don't get to put the executable code in the environment variable it's not an RCE exploit like the last bug was.

Does anyone have confirmation that this new bug allows you to RCE with control of the value of an environment variable alone?

[timv]

As best I can tell no one has (publicly) demonstrated a mechanism to turn this into an RCE (despite efforts to do so).

http://seclists.org/oss-sec/2014/q3/679

Of course, that doesn't mean there isn't one. It's clearly a reasonably significant issue - the setting of environment variables can cause unintended file system writes (and the same parsing bug can be used for reads) - and you're better off assuming that someone will determine an exploit based on it.

[thaumaturgy]

That was my initial reaction too, but I'm not so sure now that the bash maintainer has responded. I'm trying to get a better PoC working.

edit: OK, I give. I don't understand how this is different from,

    env z='' echo oops

So, assuming you have Stupid Server 2.0, and SS 2.0 allows you to send an Accept: header with,

    '' evil command here

...you still need to find a way to execute that command, which is different from CVE-2014-6271, which caused function embedded in environment variables to be executed when they were read.

Am I missing something?

[timv]

Am I missing something?

I think so, but the sample exploit isn't really designed to give a clear understanding if you don't already know what's going on.

Try this:

  $ export X="() { (a)=>\\"
  $ bash -c 'echo date'
  bash: X: line 1: syntax error near unexpected token `='
  bash: X: line 1: `'
  bash: error importing function definition for `X'
  $ cat echo
  Thu Sep 25 02:27:07 UTC 2014

Setting "X" in that way confuses the bash env variable parser. It barfs at the "=" and leaves the ">\" unparsed

AFAICT (without digging deep into the code) that leave in the execution buffer as ">\[NEWLINE]echo date" which gets treated the same as

  date > echo

[thaumaturgy]

Oh that's neat.