Message-ID: <3E3807D7.4000204@thievco.com>
From: BlueBoar at thievco.com (Blue Boar)
Subject: [Secure Network Operations,
 Inc.] Full Disclosure != Exploit Release

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

Powered by blists - more mailing lists