Bugtraq mailing list archives

Re: RE: Six Step IE Remote Compromise Cache Attack


From: "Steven M. Christey" <coley () mitre org>
Date: Wed, 5 Nov 2003 20:27:41 -0500 (EST)


Thor Larholm said:

This post raises an interesting question. Is our goal to find new
vulnerabilities and attack vectors to help secure users and critical
infrastructures, or is our goal to ease exploitation of existing
vulnerabilities?

There are no new vulnerabilities or techniques highlighted in this
attack (which is what it is), just a combination of several already
known vulnerabilities.

Maybe I'm alone in this, but I find web browser bugs like these to be
among the most complex and difficult-to-understand vulnerabilities
that get reported.  An aspect of that complexity often seems to
involve crossing several intended security "boundaries" in the
process, taking advantage of design choices that, by themselves, don't
seem to be that security-relevant.  Example: one might think that
non-random locations for software components would be a good thing,
but it's a factor in a number of web client bugs.  (Another aspect of
that complexity comes from advisories that simply include exploit code
using obscure components or elements but don't suggest where the issue
actually lies, but that's a different matter.)

I can only think of a handful of examples of "vulnerability chains"
within the same software package, but web clients seem to be a
consistent source of these chains (web servers too, probably, and
anything where a variety of components can be "glued" together).  It
wouldn't surprise me if most "in-package vulnerability chains" have
one or more vulnerabilities that are very low risk in and of
themselves, but critical to exploiting the chains.  (And back to the
subject of advisories, I've noticed that some researchers will treat
vulnerability chains as if they are entirely separate
vulnerabilities.)

Taking a long-term view with respect to vulnerability research in
general: understanding these attacks, and why they work, could provide
valuable lessons for any other software that attempts to define and
control access between different "security zones."  This assumes that
these attacks can be classified in a way that clarifies the nature of
the underlying vulnerabilities and associated chains, but as Seth
Arnold pointed out, it could be beneficial for understanding how to
properly integrate security into engineering.

- Steve


Current thread: