bugtraq - Re: RE: Six Step IE Remote Compromise Cache Attack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <200311060127.hA61Rfdd019307@linus.mitre.org>
Date: Wed, 5 Nov 2003 20:27:41 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: thor@...x.com
Cc: bugtraq@...urityfocus.com
Subject: Re: RE: Six Step IE Remote Compromise Cache Attack

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