Matt Zimmerman wrote:
> It might be a good idea to specify how quoting should be handled, both for
> shell metacharacters and format specifiers.
Well, it's been discussed several times before, but what the hey, I
guess I can discuss it one more time.
My browser proposal assumes that sensible-browser and/or the actual
browser itself not be called via system or other shell interfaces. With
that caveat, they are secure from url attacks.
> 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.
No, the caller MUST NOT pass urls through the shell in order to be
secure.
Quoting an earlier post of mine in response to Ian Jackson raising the same
question, archived in this same bug report:
The code in Debian already (see the sensible-browser program) does not
let BROWSER touch a shell. If BROWSER contains a %s then the command is
all parsed into words, substituted, and the browser execed. Just as Ian
goes on to suggest we do, except we keep the %s available as the
upstream BROWSER environment variable spec calls for, with no additional
security issue. I think there was already a thread about this.
The only possible security problem comes if some badly behaved program
does this:
system("sensible-browser '<url>'");
Such programs are broken, but it's breakage outside the scope of this
proposal. I'd be happy to see someone make a proposal that programs not
pass any kind of tainted data through the shell, ever, but someone else
will need to work on that. :-)
Every program I have converted to comply with the browser policy calls
sensible-browser safely, using exec, or parses BROWSER on its own and
runs the browser itself safely, using exec.
> 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.
The %s thing can only be injected by a user modifying his own BROWSER
variable. I think we can assume such a user already has shell access.
> 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
Except that in the current implementation in sensible-browser, the above
attack does not work. (BROWSER is split into words, the %s is substituted,
and the lot is passed to exec[1]) ESR clearly did not think much about
security when designing the upstream proposal, but it is not impossible to
implement it safely.
> Also, www.tuxedo.org/~esr/ is no more. A working URL is:
>
> http://catb.org/~esr/BROWSER/
Good catch, consider my proposal updated.
--
see shy jo
[1] My invocation of exec in sensible-browser may not be immediatly obvious,
since it looks like "system", but read the perl manual. Vive la
obfuscation.
Attachment:
pgpj3triYEUBr.pgp
Description: PGP signature