4 ms·

They don't need to. "\" isn't an escape sequence inside single-quotes. echo 'abc\' will echo 4 characters: a , b , c and \ The \' in the original command i

by timv 12y ago

They don't need to. "\" isn't an escape sequence inside single-quotes. echo 'abc\' will echo 4 characters: a , b , c and \ The \' in the original command isn't trying to escape the quote, it's ending the environment variable in a "\"

spydum 12y ago
not sure I follow this either. So you are setting a variable with a function def which is not supposed to be allowed, and calling bash. Is the naughty thing that the improper function def is supposed to prevent bash to be executed? If so, I still dont get how this is a possible RCE. nothing from the environment variable definition persists.
- timv 12y ago
  Reproduced from other discussion thread Try this slight variation: $ 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 It causes the command to be interpreted (executed) in a totally different way than it was supposed to, with the nice side effect of modifying files. See one of my other comments for an example that uses the same flaw to read files. I don't think anyone has found an RCE path for it yet though.
  - spydum 12y ago
    Thanks, that does entirely clear it up for me: I was missing the obvious (in hindsight): Under normal circumstances: $ bash -c 'echo date' date With this attack, it is not going to print out the actual date, but is actually executing something like date > echo: So what happens then as you and others demonstrated: $ 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 Wed Sep 24 22:38:19 EDT 2014 "echo" is now a file in my current working dir. Definitely fishy business. .. the whole flip flop of echo date to date > echo so easy to miss

by timv 12y ago

spydum 12y ago

not sure I follow this either. So you are setting a variable with a function def which is not supposed to be allowed, and calling bash. Is the naughty thing that the improper function def is supposed to prevent bash to be executed? If so, I still dont get how this is a possible RCE. nothing from the environment variable definition persists.

timv 12y ago
Reproduced from other discussion thread Try this slight variation: $ 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 It causes the command to be interpreted (executed) in a totally different way than it was supposed to, with the nice side effect of modifying files. See one of my other comments for an example that uses the same flaw to read files. I don't think anyone has found an RCE path for it yet though.
- spydum 12y ago
  Thanks, that does entirely clear it up for me: I was missing the obvious (in hindsight): Under normal circumstances: $ bash -c 'echo date' date With this attack, it is not going to print out the actual date, but is actually executing something like date > echo: So what happens then as you and others demonstrated: $ 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 Wed Sep 24 22:38:19 EDT 2014 "echo" is now a file in my current working dir. Definitely fishy business. .. the whole flip flop of echo date to date > echo so easy to miss