Unfortunately the patch given is insufficient for the general case.
It appears that swish-e spawns everything through the shell "sh -c
'command'"[1]. Parameters within command are not quoted.
This has serious implications, for example when scanning the file:
/jade/fileserver/home/ivtintranet/forgetter/sitebuilder/memory/data/I can't
rememeber/hello.ps
using the Filter:
FileFilter .ps pstotext
The command line becomes:
[pid 10852] execve("/bin/sh", ["sh", "-c", "pstotext
\'/jade/fileserver/home/ivtintranet/forgetter/sitebuilder/memory/data/I can\'t
rememeber/hello.ps\'
\'/jade/fileserver/home/ivtintranet/forgetter/sitebuilder/memory/data/I can\'t
rememeber/hello.ps\'"], [/* 23 vars */]) = 0
which in turn spawns:
[pid 10852] execve("/usr/bin/pstotext", ["pstotext",
"/jade/fileserver/home/ivtintranet/forgetter/sitebuilder/memory/data/I cant",
"rememeber/hello.ps
/jade/fileserver/home/ivtintranet/forgetter/sitebuilder/memory/data/I", "cant
rememeber/hello.ps"], [/* 22 vars */]) = 0
Which obviously fails.
This could be a security issue if indexing files from untrusted source,
as attacker could pick filenames like
hi'; rm -rf /; 'echo there
and trick swish-e to run sh in such a way it runs the rm -rf command.
There is also a similar bug within pstotext, see bug #356988 - the
solution might be similar.
An alternative solution is what swish++ does: it quotes all special
characters before parsing them to the shell, however far safer and
simpler IMHO is not to run the shell in the first place.
Notes:
[1] I would sooner it didn't run the shell- running the shell wastes
time and probably isn't required for most (if not all filters).
--
Brian May <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
