On Sun, Aug 03, 2003 at 11:03:21PM -0400, Joey Hess wrote: > 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.
The problem is that the proposal says to implement the BROWSER specification, and the BROWSER specification says that the elements of $BROWSER are "commands". This is not a very exact specification, but the logical interpretation is that they are shell commands, and the examples demonstrate that. > Quoting an earlier post of mine in response to Ian Jackson raising the same > question, archived in this same bug report: Hmm, I missed that reply. > 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. OK, so we already don't implement esr's BROWSER as specified. That doesn't bother me at all. The specification we do use is not complex; why not just specify what we really want directly in the document and remove the references to esr's BROWSER altogether? Our specification is a subset of that one, which only supports space-separated words rather than shell semantics. > > 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. Hmm, that's true, unless the implementation is very stupid. Never mind. > 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. In making it safe, you are no longer implementing esr's specification. It will break on nontrivial cases, such as the -remote commands for netscape: BROWSER="netscape -raise -remote \"openURL(%s, new-window)\":lynx" (note the embedded space inside the argument to -remote) is perfectly valid as a shell command, but would presumably break sensible-browser. -- - mdz
