BitJam
@skidoo, I don’t think escaping will be sure to save you but there is an easy solution. The easy solution is to only allow certain characters that we know are safe. Either balk at or remove unsafe characters.
I am still unclear on when the problem occurs. For example changes to gksu can’t help this:
gksu --su-mode echo "hello$(touch /tmp/boom)"
because the double-quoted string is evaluated by the shell when it calls gksu, not by gksu or by echo. But you can protect against:
gksu --su-mode echo 'hello$(touch /tmp/boom)'
by cleansing all the input strings. I do something like this for all of the translation strings used in our Bash scripts and our live-initrd. There is really no need for people to be using “fancy” characters like $ and back-tic in arguments to gksu so I think it is safer to just ban them IMO. There is no need to have $ or back-tic in a command name, a command option, or a filename. They have not been needed in any of the translation strings I have cleansed although I have the option of adding unsafe characters using %s with printf. But by doing this they are no longer unsafe.
ISTM that if you limit the space of characters that are allowed then you can be sure you are safe and IMO the limitation is far from onerous. For the translations strings, all non-literal characters are banned. I think you can use a regex to remove the bad chars (or only preserve the good chars) and then compare with the original string although it might be dangerous to shell out to tr or sed to do this.
Just my 2 cents.
[...] almost any English person would accept "bully" as a synonym for "Fascist". -- George Orwell (1944)