Bug#172436: Security concerns regarding browser proposal
It might be a good idea to specify how quoting should be handled, both for
shell metacharacters and format specifiers.
>From the existing text, it seems that "command part" means "shell command
part", and it is impossible to implement this securely without specifying a
scheme for handling shell metacharacters. See, for example, the recent xpdf
discussions, where the URL-handling command could be exploited by a URL
containing metacharacters if it did not quote the argument. Even if the
command includes quotes around a substitution variable such as %s, the
caller MUST quote any quote characters in the URL itself in order to be
secure.
The semantics for %s and %% so closely match printf that they beg to be
implemented using printf itself. This means that % characters also present
a security risk through well-known format string attacks.
If we were starting from scratch, it would be simpler to address these
concerns, but since we are trying to follow esr's proposal, it seems more
complicated. I consider the specification to be flawed if it does not
address these security concerns. The example given in esr's document:
BROWSER="netscape -raise -remote \"openURL(%s,new-window)\":lynx"
is easily exploited by a URL such as:
http://my.fun.site/";; echo Do bad things
(with a bit more cleverness it might be possible even to conceal the error
message that would be generated)
Also, www.tuxedo.org/~esr/ is no more. A working URL is:
http://catb.org/~esr/BROWSER/
--
- mdz
Reply to: