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.
