Bugtraq mailing list archives
Re: Six Step IE Remote Compromise Cache Attack
From: Florian Weimer <fw () deneb enyo de>
Date: Thu, 6 Nov 2003 00:25:05 +0100
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?
With Internet Explorer, Microsoft is exactly in the position that was the original motivation for full disclosure -- force the vendor to fix the bugs. The reasons are different (very risk-prone design; for example, any ActiveX control can break the entire security policy), and Microsoft isn't ignoring the problems altogether. But the end result is nearly the same: lot's of unfixed, more-or-less well-known bugs. You can deal with this situation in a few ways: ignore it, and hope for the best; try to surpress information about vulnerability details; choose safer settings (breaking many, many web pages); prevent users from browsing the web using Internet Explorer (with or without disabling plugins of questionable code quality, i.e. all of them); gamble with virus scanners and special proxies; restrict Web access to separate terminals, and so on. However, none of these approaches makes the problem go away. I still believe that the client is lost, and will remain lost for quite some time. As far as I know, this view isn't shared by Microsoft engineers. They reason that the company is pretty good at patch management, much better than the competition. Maybe Microsoft has a true advantage over the rest of the industry here (I wouldn't rule out that possibility), but in the best case, your patch management is only as good as the patches you can apply. If the developers have to deal with a substantial backlog of unfixed security issues, both published and unpublished, it's not very likely that the right patches are available in time. So far, we have been rather lucky. Note that this discussion completely ignores the poor, poor home users. I have no idea how the situation can be improved for them, in particular if they run illegal software copies and fear to download and apply any vendor patches.
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 understand your concern, and share it in some cases, especially if I assume that most people are already sensitive to the threat. I don't see that for Internet Explorer, so further education seems to be necessary, even if it takes rather drastic forms.
Current thread:
- Six Step IE Remote Compromise Cache Attack Liu Die Yu (Nov 05)
- <Possible follow-ups>
- RE: Six Step IE Remote Compromise Cache Attack Thor Larholm (Nov 05)
- RE: Six Step IE Remote Compromise Cache Attack Steve Hillier (Nov 05)
- RE: Six Step IE Remote Compromise Cache Attack Benjamin Franz (Nov 05)
- 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 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)