Bug#172436: Security concerns regarding browser proposal
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
Reply to: