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:
- RE: Six Step IE Remote Compromise Cache Attack, (continued)
- RE: Six Step IE Remote Compromise Cache Attack white colin john (Nov 05)
- RE: Six Step IE Remote Compromise Cache Attack Tyler Larson (Nov 06)
- Re: Six Step IE Remote Compromise Cache Attack Florian Weimer (Nov 07)
- RE: Six Step IE Remote Compromise Cache Attack white colin john (Nov 05)
- Re: Six Step IE Remote Compromise Cache Attack Florian Weimer (Nov 05)
- Re: Six Step IE Remote Compromise Cache Attack Seth Arnold (Nov 05)
- Re: Six Step IE Remote Compromise Cache Attack Jelmer (Nov 06)
- RE: Six Step IE Remote Compromise Cache Attack Thor Larholm (Nov 05)
- RE: Six Step IE Remote Compromise Cache Attack Paul Szabo (Nov 05)
- RE: Six Step IE Remote Compromise Cache Attack Drew Copley (Nov 06)
- Re: Six Step IE Remote Compromise Cache Attack http-equiv () excite com (Nov 06)
- Re: RE: Six Step IE Remote Compromise Cache Attack Steven M. Christey (Nov 06)
- Re: RE: Six Step IE Remote Compromise Cache Attack Paul Schmehl (Nov 06)
- RE: Six Step IE Remote Compromise Cache Attack Steven M. Christey (Nov 07)
- Re: Six Step IE Remote Compromise Cache Attack Goetz Babin-Ebell (Nov 10)
- Re: Six Step IE Remote Compromise Cache Attack Byron Sonne (Nov 10)
- RE: Six Step IE Remote Compromise Cache Attack Alun Jones (Nov 11)
- Re: Six Step IE Remote Compromise Cache Attack Goetz Babin-Ebell (Nov 10)
- Re: Six Step IE Remote Compromise Cache Attack Steven M. Christey (Nov 10)
- RE: Six Step IE Remote Compromise Cache Attack Michael Wojcik (Nov 11)
- Re: Six Step IE Remote Compromise Cache Attack Goetz Babin-Ebell (Nov 11)