Date: Thu,  6 Nov 2003 11:55:19 -0600
From: Tyler Larson <noreply@...rson.com>
To: white colin john <cjwhite1@...nx13.ews.uiuc.edu>
Cc: bugtraq@...urityfocus.com
Subject: RE: Six Step IE Remote Compromise Cache Attack


Quoting white colin john <cjwhite1@...nx13.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.

Powered by blists - more mailing lists