Full Disclosure mailing list archives

Re: RE : RE : [Secure Network Operations, Inc.] FullDisclosure != Exploit Release


From: hellNbak <hellnbak () nmrc org>
Date: Tue, 28 Jan 2003 23:17:12 -0600 (CST)

On 28 Jan 2003, Strategic Reconnaissance Team wrote:

Date: 28 Jan 2003 20:02:59 -0500
From: Strategic Reconnaissance Team <recon () snosoft com>
To: Nicolas Villatte <Nicolas.Villatte () advalvas be>
Cc: full-disclosure () lists netsys com
Subject: Re: RE : RE : [Full-disclosure] [Secure Network Operations,
     Inc.] FullDisclosure != Exploit Release

Good points,
      One question remains however.  If we are to attach exploit code to our
advisories, how do we protect the innocent from attacks by malicious
people using our exploit code? I honestly believe that exploits are
digital munitions that should be distributed under restrictions. Do you
agree that a vulnerability can be clearly demonstrated in an advisory by
showing debugger output and explaining the output? If proof of concept
code needs to be made, it could be generated from the detail in the
advisory. Why is that not a solution?

I agree with this argument -- mostly.  If I read this correct, you are
still going to release full vuln details in the advisory.  This keeps the
code away from those who do not have the ability to take the advisory and
turn it into their own exploit.

The common argument that is made (and that I agree with) is that IT guys,
don't have the time and don't always have the skill to come up with their
own exploit code.  Combine this with the fact that they don't have the
budget to buy a commercial scanner and there is no way their boss will
allow something scary like Nessus on their network (these organizations
exist).  So how can an IT guy test a patch?  How can he be sure that the
vendor has done their jobs?

Now if you agree with my first few sentences and do release complete
details yes, you have achieved the objective  of protecting the world from
script kiddies and clueless consultants <---- this is a great thing.  But,
as you said the complete vulnerability information is enough information
to make your own exploit so you have not eliminated the true blackhats or
anyone (white, purple, grey, whateverhat) that can create their own
exploit based on the info.

So, the defenseless are still defenseless and the malicious are still
armed.  So is the answer not dislcosing details?  I would say no as the
simple statement "there is an overflow in xyz.dll" is enough to make those
with the abilities look at xyz.dll and find it.  So how about no
disclosure?  Great, now we are all only as good as our own and our friends
research.  Meaning more of us are at risk.

So I say release the code, try and make it as crippled as possible
(localhost only or whatever) so at least you know that *your* code won't
be directly used for malicious intent.  Yeah exploits and malicious
code/worms/virus'/whatever will still exist and be abused but regardless
of what you and anyone else for that matter do it always will.

At least with releasing code you can take comfort in knowing that you are
helping those who cannot help themselves.  That is of course if you
believe in helping others and don't just release advisories for the
media-whoring marketing purposes (hello to my friends at ISS ;p).


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

"I don't intend to offend, I offend with my intent"

hellNbak () nmrc org
http://www.nmrc.org/~hellnbak

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


Current thread: