Re: [Inkscape-devel] Escaping $ in commandline parameters
Ted wrote:
Kees, is there some way to validate a command line to make sure you're not causing any security holes by calling shell variables that you don't mean to? It seems like there should be something generic out there.
Sorry, I'm way busy. From the looks of it, glib provides g_shell_quote(), which should be used in a per-argument fasion. e.g. if the extension is running:
PROGRAM ARG1 ARG2 SVGPATH
via something like:
sprintf("%s %s %s %s", program, arg1, arg1, path);
Then each element should be quoted:
prog_q = g_shell_quote(program); arg1_q = g_shell_quote(arg1); arg2_q = g_shell_quote(arg2); path_q = g_shell_quote(path); sprintf("%s %s %s %s", prog_q, arg1_q, arg2_q, path_q); g_free(prog_q); g_free(arg1_q); g_free(arg2_q); g_free(path_q);
However, I much more recommend using arrays for doing execution, since that forces the right arguments and stops any kind of shell expansion.
On Tue, Apr 10, 2007 at 05:35:46PM -0700, Kees Cook wrote:
However, I much more recommend using arrays for doing execution, since that forces the right arguments and stops any kind of shell expansion.
BTW, after digging around and finding the code in extension/implementation/script.cpp, and seeing the "pipe_t" class, this whole infrastructure needs o be replaced with g_spawn_async_with_pipes() and the usage of arrays for execution instead of strings. This should reduce the size of the code, make it much easier to maintain, and end up being much much safer.
On Tue, 2007-04-10 at 18:28 -0700, Kees Cook wrote:
On Tue, Apr 10, 2007 at 05:35:46PM -0700, Kees Cook wrote:
However, I much more recommend using arrays for doing execution, since that forces the right arguments and stops any kind of shell expansion.
BTW, after digging around and finding the code in extension/implementation/script.cpp, and seeing the "pipe_t" class, this whole infrastructure needs o be replaced with g_spawn_async_with_pipes() and the usage of arrays for execution instead of strings. This should reduce the size of the code, make it much easier to maintain, and end up being much much safer.
Cool, thanks Kees. Now do you have to write up an exploit for this? ;)
--Ted
On Tue, Apr 10, 2007 at 11:12:17PM -0700, Ted Gould wrote:
Cool, thanks Kees. Now do you have to write up an exploit for this? ;)
Heh, nah; currently it is only "exploitable" by people typing stuff into parameter windows or making their own evil .inx files. If anyone wants to hack themselves, I don't want to stand in the way. :)
But, going forward, it should be fixed in case extension scripts become easier to 'share' in the future, etc etc.
On Wed, 2007-04-11 at 07:46 -0700, Kees Cook wrote:
On Tue, Apr 10, 2007 at 11:12:17PM -0700, Ted Gould wrote:
Cool, thanks Kees. Now do you have to write up an exploit for this? ;)
Heh, nah; currently it is only "exploitable" by people typing stuff into parameter windows or making their own evil .inx files. If anyone wants to hack themselves, I don't want to stand in the way. :)
But, going forward, it should be fixed in case extension scripts become easier to 'share' in the future, etc etc.
Okay, the only reason I was curious is because users can install extensions in their home directory and Inkscape will pick them up. They would still have to download it, so I guess the worst case is some sort of trojan horse type thing where a potentially malicious extension is advertised as being really useful.
--Ted
On Wed, Apr 11, 2007 at 09:56:37AM -0700, Ted Gould wrote:
Okay, the only reason I was curious is because users can install extensions in their home directory and Inkscape will pick them up. They would still have to download it, so I guess the worst case is some sort of trojan horse type thing where a potentially malicious extension is advertised as being really useful.
Sure. But no Inkscape security will stop people from downloading a .inx with <command>rm -rf /</command> in it. :)
participants (2)
-
Kees Cook -
Ted Gould