[Geany-Devel] Escaping replacement for placeholder in build commands
Colomban Wendling
lists.ban at herbesfolles.org
Sat Dec 15 13:52:37 UTC 2012
Le 15/12/2012 06:58, Matthew Brush a écrit :
> On 12-12-14 08:34 PM, Lex Trotman wrote:
>> On 15 December 2012 03:53, Colomban Wendling
>> <lists.ban at herbesfolles.org> wrote:
>>> Hi guys,
>>>
>>> You probably saw the mail from Jan Lieskovsky about the "security issue"
>>> of not escaping filenames and other placeholders in the build commands.
>>
>> Hi Colomban,
>>
>> No, a reference would be useful ;).
>>
>
> It was sent directly to Geany developers, regarding:
> https://bugs.gentoo.org/show_bug.cgi?id=446986
Thanks Matthew. And sorry Lex, I didn't think you might not have got it.
>>> Although I don't really think it's important from the security POV, I
>>> think it would be great to fix it for users not to get weird errors if
>>> their files actually contain some weird characters (even only spaces if
>>> their build command misses quoting around the placeholder).
>>
>> I don't think Geany should be interpreting what a user meant by their
>> command, there are too many edge cases that don't conform to the
>> "usual" gcc or other rules. That space may be meant to be there,
>> Geany has no way of knowing. Also what if the command has globs in
>> it, quoting them stops them working :(
Calm down Lex, I'm not trying to break your whole Geany. Breathe.
Inspire; Expire. Ok ;)
> I think the idea is to just escape the filenames being replaced into %f
> et al placeholders, not the whole command en masse. IIRC, the only thing
> placed into the placeholders is filenames/paths, which should be able to
> be safely escaped/sanitized without messing up the whole command.
That's it. Another example like Matthew's one: what I want to do is
only to make sure that e.g. "%f" is never replaced by something that
will be interpreted as a command. Those placeholders (%f, %d, %e and
%p) represent filenames or paths and never user-typed commands, so they
should never be interpreted as a command.
For example, the simple command:
gcc "%f" -c -o "%e.o"
Given the current file named:
holy "crap.c
would currently expand to:
gcc "holy "crap.c" -c -o "holy "crap.o"
Which, huh, doesn't mean what you want at all! The commands will be
understood as:
argv[0] = gcc
argv[1] = holy crap.c -c -o holy
argv[2] = crap.o
(if my shell unquoting skills are correct ;))
What the user actually expected was:
argv[0] = gcc
argv[1] = holy "crap.c
argv[2] = -c
argv[3] = -o
argv[4] = holy "crap.o
Obviously, it's not the same :(
So again, what I want is to make sure the placeholders (%f & co.) are
properly escaped/quoted/whatever so they never get misinterpreted like
above. And as I said, to actually achieve this we have to somewhat
understand the quoting in the user command because we can't escape the
same inside or outside shell quotes -- e.g. %f (without quotes) cannot
be escaped the same way as "%f" (with the quotes).
But still nothing really clever trying to understand a meaning, just
knowing the basics like '' and "" are quotes, and \ is an escape so we
can know how to escape. Actually the implementation I proposed simply
closes any open quote before replacing a quoted placeholder, and then
re-opens it.
I.e. for the above example, it would replace as:
gcc ""'holy "crap.c'"" -c -o ""'holy "crap.o'""
That's a bit ugly but you don't have to see it, and it's perfectly safe.
Also, just to make sure you see what I mean, if the user command didn't
quote the %f and %e, and the filename simply contained a space:
command: gcc %f -c -o %e.o
filename: file name.c
current replacement: gcc file name.c -c -o file name.o
fixed replacement: gcc 'file name.c' -c -o 'file name'.o
You see? :)
>
>>>
>>> So, how to fix it?
>>
>> Don't, its not broke :)
Yes it is, although it's not really annoying because commands have
quotes around placeholders and filenames generally don't include "
literals. But try compiling a file whose name contains a " literal and
you'll see it's broken ;)
Hope it's clearer now :)
Cheers,
Colomban
More information about the Devel
mailing list