Message-ID: <1043868817.4467.155.camel@localhost.localdomain>
From: recon at snosoft.com (Strategic Reconnaissance Team)
Subject: [Secure Network Operations, Inc.] Full
	Disclosure != Exploit Release

Blue Boar, 
	Very good points.  I've considered most of these and they all make
sense. As far as corporate politics are concerned, don't you think that
exploit disclosure could hurt vendor relationships? Granted, we are not
going to make our decision on that premise but it would be a nice thing
to avoid. 


On Wed, 2003-01-29 at 11:56, Blue Boar wrote:
> Strategic Reconnaissance Team wrote:
> > The focus of the message was to help
> > determine legitimate reasons, if any, to release proof of concept code
> > to everyone.
> 
> Here are a few reasons why I believe releasing full exploits has merit:
> 
> - If a full exploit is available to the world, then there is much less 
> incentive for others to write their own exploit.  This means defenders will 
> have a smaller base of attack code to deal with.  If you're trying to write 
> an IDS rule, for example, and the IDS cannot effectively detect the general 
> case of exploitation for that vulnerability, then you have to write an 
> exploit-specific rule.  (Yes, this is a failing on the part of the IDS, but 
> that's reality.)  This is especially useful when a worm based on the same 
> code rolls around.  Any attempt at crippling exploits still leads to futher 
> variations being written.
> 
> - If an exploit is available (and it works, obviously) then no one can 
> argue about whether the problem can be exploited.  You can perhaps argue 
> that it's MORE exploitable than the exploit shows, but not less.
> 
> - The vendor can't effectively claim the prolem is less serious than it is.
> 
> - Customers can test for themselves whether a patch works or was applied 
> correctly.
> 
> - Customers can test other versions of the product besides the ones 
> mentioned in the advisory are vulnerable, including those that have been EOL'd.
> 
> - Customers can scan their networks looking for vulnerable hosts.  SOme 
> percentage of vulnerable software cannot be detected based on banner 
> scanning (remotely.)
> 
> - Penetration testers have another tool to do their job.
> 
> - The advisory can be independently verified (I've looked at numerous 
> vulnerabilies where the advisory wasn't very good, but the exploit allowed 
> the problems to be verified.  I've seen cases where the advisory was just 
> plain wrong, and the exploit at least demonstrated what they found, so it 
> could be properly documented.)
> 
> - The company security guy can prove the risk to the clueless if he needs 
> to.  (When I was a corporate security guy, I unfortunately was called upon 
> a few times to "prove it" when discussing a problem in order to get changes 
> to happen.  One does not always have the time, inclination, or skill to 
> produce their own exploits.)
> 
> - Having an exploit available will make things easier for people writing 
> scanners, for example Nessus.
> 
> - Having an exploit available for study will allow researchers to determine 
> what the affects of exploitation are, such as services chrashing, what the 
> log entries look like, what happens with an unsuccesful exploitation, etc...
> 
> - Time is saved by not having to reinvent the wheel.
> 
> This is not a complete list, just what I could think of off the top of my 
> head.  I realize that some people will see the same points as reasons to 
> NOT release exploits.  I realize there may be lots of counter-arguments to 
> my points, and many people will have a different opinion.  I'm just 
> answering the question as asked.
> 
> 					BB
-- 
Strategic Reconnaissance Team <recon@...soft.com>
Secure Network Operations, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030129/10494aec/attachment.bin

Powered by blists - more mailing lists