Re: [Chicken-hackers] [patch] utils: qs not escaping pipes

[Michele La Monaca]

On Sun, Feb 17, 2013 at 3:22 PM, Florian Zumbiehl <address@hidden> 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