On Sun, Feb 17, 2013 at 3:22 PM, Florian Zumbiehl <[email protected]> wrote: > Hi, > > I noticed that qs doesn't escape pipe characters.
It doesn't escape '=' neither. Shell escaping, as strange as it sounds, is position dependent. Suppose you have a program named 'l=s' in your PATH. While e.g. you can delete it without escaping: # rm /<path>/l=s you can't run it as it is, since # l=s will simply set the variable 'l'. The escaped versions: # l\=s # 'l=s' will do the job. I'm not a security expert, but maybe this behavior can be even exploited somehow in a poorly-written program which forks qs-escaped strings. For example: (process-run (string-append (qs "l=s") " " (qs "evil-program"))) will start 'evil-program' instead of 'l=s'. > I suggest the patch below, which not only makes it so that pipes get escaped, > but it also switches away from the blacklist approach, which invariably > doesn't > work ;-) While I agree that the proposed patch is the safest approach and should be the default behavior, I would retain the backslash-based escaping as an option if possible. Backslash-based escaping is quite common and should be available to the user in my opinion. For example, this kind of escaping is the one provided by bash's builtin printf function: # printf %q "it's a dark, rainy night" it\'s\ a\ dark\,\ rainy\ night In this regard, I think that switching from a blacklist to a whitelist approach should be reasonble safe. Regards, Michele _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
