KShell & KMacroExpander - are we screwed?
apaku at gmx.de
Sun Oct 14 23:27:37 CEST 2007
On 05.10.07 15:52:01, Oswald Buddenhagen wrote:
> possible solutions:
> - ignore the problem. assume that a) regular urls, filenames, etc.
> don't produce existing variable names by chance and b) the regular
> environment does not contain anything dangerous and an attacker
> won't be able to manipulate the environment, so passing weird
> parameters intentioally won't help him.
> i guess anybody who considers this solution seriously should be shot.
> - ban % from arguments. unrealistic - too common in urls. also,
> implementing error paths would mean quite some api magic now.
> - screw cmd, v1: kprocess::setshellcommand is nuked again (at least on
> windows). user-provided commands are only subjected to
> kshell::splitargs and direct execution via kprocess (is special
> support for batch files needed?). the fear is that removing the
> kprocess function will only lead to devs home-growing equivalent code
> which is even worse, usually.
> v1a (applicable only to KRun, as the other variants have no proper
> error reporting facilities): refuse commands that contain % and at the
> same time reqire a shell. eeek.
> - screw cmd, v2: use a posix shell under windows. things would be so
> much simpler for kde developers. windows power users would be
> surprised at first. otoh, they should be used to a complete lack of
> consistency when it comes to command lines. :=)
> unless somebody has a better idea, i vote for screw cmd v2, and as a
> last resort v1 for windows only.
Ok, I read the mail, multiple times. But I still don't really understand
the problems, I think. What I did understand is even if people use
KShell::quoteargs and Co. for a given user-supplied command that should
be executed via a shell, there's still the risk of executing something
like rmdir c:\ if the environment of the user gets prepared properly?
Well, I'm tempted to say: go for option 1 on win32. I mean if you manage
to get your environment screwed up who knows what else goes on on that
machine, it needs a reinstall anyway. This is the same as if somebody
hacked your unix machine, just that this is more likely to happen on a
If thats not an option I think I vote for screw v1. screw v2 is still
not an option, it doesn't make anything simpler for win32 kde developers
and especially not for the users. Those users would have to adopt the
commands and arguments to posix shell, which you can't really expect
Accent on helpful side of your nature. Drain the moat.
More information about the Kde-windows