Bugtraq mailing list archives
RE: Six Step IE Remote Compromise Cache Attack
From: Tyler Larson <noreply () tlarson com>
Date: Thu, 6 Nov 2003 11:55:19 -0600
Quoting white colin john <cjwhite1 () ehlnx13 ews uiuc edu>:
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?If there's no proof-of-concept that shows current bugs can be combined into an exploit, is there any pressure on microsoft to patch the bugs?
I'm surprised that nobody has taken issue with this statement. I think that in this case Msft would continue to drag its feet for years to come, and Liu was justified in posting the exploit. However, I think that in the general case (expecially those dealing with entities other than Msft) the statement is not always accurate. When dealing with projects and organizations with security-minded developers-- take the OpenSSH project or vsftpd, for example--extremely little coersion is necessary. Just email the developer and he'll fix it immediately. In fact, I'd go as far as to say that in dealing with any open-source software at all, development of a POC exploit is never necessary. It's generally easier (and always more productive) to develop the fix than the POC anyway. And if a vendor patch exists, POC code won't help anybody. Why? Because the existance of a security patch already adequately demonstrates the existance of a potential threat. People who develop exploit code should think REAL HARD about why they're doing it before they start. If you're writing it simply because nobody else has yet, you should definately reconsider: there's probably reasons why no one has written it before--do you really think you're the first one to know how? If you're trying to impress you're peers (i.e. get a job) think again. Attention you get by acting irresponsibly is not the attention you want. If attention is a motive, it should be a secondary motive rather than a driving one--otherwise it gets in the way of common sense. Attract attention while doing the "right thing" (i.e. developing POC exploits only when they're needed). It produces better results anyway. As stated before by others, proof-of-concept exploit code serves one major purpose: It lights a fire under a slow-moving organization to quickly develop a fix. It's important to understand how, though. It does it by: * Convincing the company that the threat is real. We like to think this is all we're doing, but it's only a very small part of the process. * Increasing the threat by aiding in the development of worms and viruses. Sad but true, this is a major reason why exploit code speeds things up. * Turning public opinion against the company. They clean it up only because it would be a PR nightmare if they didn't. Exploits, even POC exploits, do a LOT of damage, whether you like to belive it or not. That's the whole reason why they work--they absolutely force the company to fix the problem in order to stop the bleeding. That's why Microsoft HATES the whole concept of full disclosure (a few choice Ballmer quotes may come to mind). There's really nothing innocent or harmless about it. In certain situations, though, the general pubic (though probably not the company) is better off because the exploits forces the company to fix its mistakes. In those select few situations, I say the developer is justified in writing the exploit. The rest of the time, though, I say he's just being a public menace.
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)