[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <200710102347.l9ANlBCB012303@faron.mitre.org>
Date: Wed, 10 Oct 2007 19:47:11 -0400 (EDT)
From: "Steven M. Christey" <coley@...re.org>
To: bugtraq@...urityfocus.com
Subject: URI handling as the harbinger of interaction errors
Throughout this whole discussion on URI handling and IE, let's not
forget that:
1) ANY technology that uses "handlers" that pass commands and
arguments from one process to another, is likely to have these
kinds of issues. Web browsers are just the first to get this kind
of attention. All products that support plugins, whether web-based
or not, should be examined for this type of problem.
2) Programs that were formerly assumed to be safe because they were
only ever intended to be invoked by a single user, will now become
unsafe if they're referenced in a handler. Think second-order
symlink issues as one example, or buffer overflows in command-line
arguments for non-setuid programs that are likely to be used in
handlers (image converters, anyone?)
3) These kinds of interaction errors, when disclosed, will probably
continue to generate widespread debate. It's the nature of
interaction errors that either side could be "blamed."
4) The best currently feasible solution is likely to require that the
invoking process stricly enforces which arguments it passes to the
invoked process. It should be obvious that string-based command
construction is too risky. Also, the invoked process might have a
default mode of operation that disallows arguments that might be
especially dangerous. This will likely break legitimate
functionality that's in active use, so adoption of such solutions
will be slow.
5) As technologies become more integrated, we're likely to see more
reports like this.
- Steve
Powered by blists - more mailing lists