bugtraq - 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44.0311051443180.10470-100000@high-mountain.nihongo.org>
Date: Wed, 5 Nov 2003 14:49:42 -0800 (PST)
From: Benjamin Franz <snowhare@...ongo.org>
To: Thor Larholm <thor@...x.com>
Cc: Liu Die Yu <liudieyuinchina@...oo.com.cn>,
	<bugtraq@...urityfocus.com>
Subject: RE: Six Step IE Remote Compromise Cache Attack

On Wed, 5 Nov 2003, Thor Larholm wrote:

> 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. This is not a proof-of-concept designed to
> highlight how a particular vulnerability works, but an exploit designed
> specifically to compromise your machine. All a malicious viruswriter has
> to do is exchange the EXE file.
> 
> Believe me, I am all in for full disclosure and detailing every aspect
> of a vulnerability to prevent future occurances of similar threats, but
> I don't particularly think that we should actively be trying to help
> malicious persons.

I have mixed emotions about this. On one side - why put millions of
systems at risk to script kiddies? On the other side, as noted by the
poster, one of these vulnerabilities has been known for more than _TWO
YEARS_. Surely far more than enough time for MS to have actually _fixed_
the problem if they intended to. MS seems (at least in some cases)  to
ignore security problems until someone publically 'holds their feet to the
fire' over them. I suspect this happens when the problem 'runs deep' in
their code and will require more than fixing a boundary limit check and
recompiling.

-- 
Benjamin Franz

Gauss's law is always true, but it is not always useful.
    -- David J. Griffiths, "Introduction to Electrodynamics"